Hi, On Sat, Aug 07, 2010 at 05:28:57PM +0200, Carl Fredrik Hammar wrote: > On Tue, Jul 27, 2010 at 08:22:14PM +0200, olafbuddenha...@gmx.net wrote:
> > GRUB effectively needs a three-way mapping between filesystems, device > > node names, and GRUB device names. The mapping between GRUB devices and > > the /dev/hd* device node names is almost trivial. (Assuming that the > > device nodes follow a standard naming scheme.) The tricky part is > > mapping filesystems either to GRUB devices *or* to device node names. > > > > Mapping directly to device node names requires a full understanding of > > the store information obtained from the filesystem (whether extracted > > from command line parameters, or with a special RPC) -- for all possible > > device schemes. Finding out the GRUB devices (using GRUB's own partition > > handling code) OTOH requires only a basic understanding of the various > > device schemes; while the blanks are filled in by a probing mechanism, > > which can be made pretty robust I believe. My current impression is that > > it's actually the more flexible solution... > > The main problem is that file_get_storage_info() might not return a > remapped version of its underlying store. In fact, the more I think > about it the more I realize that doing so is a bug. Consider what > would happen if a file that backs a filesystem is modified or removed. > Then, the mapping of the file would change but the file-backed filesystem > would continue using the old mapping that could contain blocks that are > now reused. The result would be corruption of the top-level filesystem. > Now granted, touching a file that backs a filesystem is never a good > idea, but it should never result in corruption of the filesystem that > contains the file (only the filesystem that is backed by the file). Indeed, I always considered it a bit strange that the client gets a block list -- normal clients should *never* access blocks on a partition directly, as there is no guarantee that the set of blocks backing a file is stable. > There are also other problems like the file is on a filesystem backed > by another file on a filesystem backed by a partition would result in > grub-probe mistakenly thinking that the file is on the partition. > > Still, the above would work as long as an RPC that returns the > filesystem's store, rather then the file's store, is used. Indeed, sounds like a good plan :-) -antrik-
