Messages in this thread | | | Date | Thu, 17 Jun 1999 13:42:27 +0200 | From | Matthew Wilcox <> | Subject | Re: RFC: from FIBMAP to FIONDEV |
| |
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/
| |