Re: Fixing grub-probe to work with user-space part stores

[olafBuddenhagen]

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, olafBuddenhagen@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-