Re: RFC: from FIBMAP to FIONDEV

Matthew Wilcox (Matthew.Wilcox@genedata.com)
Thu, 17 Jun 1999 13:42:27 +0200


On Thu, Jun 17, 1999 at 11:34:30AM +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Tue, 15 Jun 1999 15:58:58 +0200, Matthew Wilcox
> <Matthew.Wilcox@genedata.com> said:
>
> > RAID 2,3,4,5 return the data block on the first call and set the
> > COPIES flag. Subsequent calls set the XOR flag to indicate that the
> > other blocks should be XORed together to recover the original block.
> > lilo is perfectly free to ignore this information, but maybe someday
> > we'll have a good way to use this information.
>
> Perhaps this is just unnecessary complexity. After all,
>
> > With RAID 1, lilo can install multiple copies of LILO, one on each disc,
> > each one told about the blocks which exist on its own disc.
>
> ... this looks like exactly the right way to do things. Very nice.
> Short of booting the kernel off the network it looks like the most
> robust way of doing things right. It is not hard to reserve a small
> raid-1 partition for /boot even if the rest of your system is
> raid-<something-bigger-than-one>.

Okay, I give in. If we do wish to support RAID-1, we still need a way
of mapping one logical block to multiple physical blocks. I suggested an
index to the call, Werner suggests a variable length return. Anyone have
any strong opinions?

Note that Werner's objection to whether or not the file pointer is
advanced if one is supposed to make a repeated call can be solved by
changing FIONDEV to never advance the file pointer, after all the
application can do this for itself quite easily.

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/