Re: grub vs st_dev (aka fsid) / st_rdev

[Carl Fredrik Hammar]

On Tue, Nov 10, 2009 at 11:24:34AM +0100, Samuel Thibault wrote:
> Carl Fredrik Hammar, le Tue 10 Nov 2009 09:27:14 +0100, a écrit :
> > > - An easy way is to have storeios expose their own pid as
> > >   st_rdev, and have filesystems use the underlying storeio st_rdev for
> > >   their st_dev (aka fsid).  One issue is for the / ext2fs, since it
> > >   doesn't use a storeio, and a storeio could be started later.
> > 
> > This solution also won't work if storeio is passive, times out, and
> > is later restarted.
> 
> That's not a problem since in that case the FS above it will have to be
> restarted too. Note that a storeio can't time out while an FS is still
> running.

The FS can use file_get_storage_info and use the store directly,
after this it doesn't need storeio.  This is what ext2fs does.

> > The ideal would be to derive it from the underlying Mach device somehow.
> 
> Not all storage are Mach devices.

I assumed that was the case for the ones that are interesting for grub.

> > > - Or we make grub use a more hurdish interface, i.e.
> > >   file_get_storage_info, e.g. storeinfo -n / .
> > >   I have however observed a disturbing behavior:
> > > 
> > >   $ dd < /dev/zero > foo bs=1M count=1
> > >   $ /sbin/mke2fs -o hurd foo
> > >   $ settrans -c bar /hurd/ext2fs $PWD/foo
> > >   $ storeinfo foo/
> > >   device (0x200): hd2: 512: 8: 4096: 11848072+8
> > > 
> > >   It is indeed true that the file is actually stored in hd2, but before
> > >   that it's stored in the foo file and wouldn't be available by just
> > >   mounting hd2.
> > 
> > This is a feature, not a bug.
> 
> It is a bug to me: it should rather return a _file_ storage type, with
> the offsets etc. within the file. And then the caller can call storeinfo
> on the file itself (foo), etc.

You could get this behaviour by doing:

$ settrans -c bar /hurd/ext2fs file:$PWD/foo

But then the new ext2fs instance will also use normal file IO,
instead of using the Mach device directly.

> > The store returned by file_get_storage_info on a file in ext2fs is its
> > underlying store with a range that specifies which blocks the file is
> > stored in.  This way, clients that load the store can read directly
> > from the underlying device, assuming that they can actually open it.
> > As long as grub acknowledges the range it should be fine.
> 
> The problem is that Grub doesn't work that way: it just wants to know
> which device the volume comes from, it doesn't want the precise block,
> since it has its own ext2fs module, which allows to modify the files
> etc. without having to care about re-installing grub (i.e. not like e.g.
> lilo).

To see if a store is a real device and not a regular file, it can check
if the range covers the entire store.  I assume that Grub doesn't support
filesystems stored in files of other filesystems.

> > I think it would be better if the range was encoded in a seperate store
> > with the device as a child store.
> 
> As a parent store you mean?

This is perhaps more accurate, but in store terminology all dependencies
to other stores are called children.

Regards,
  Fredrik