Re: grub vs st_dev (aka fsid) / st_rdev

[Samuel Thibault]

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.

> It would be nice if the fsid was acctually stable accross translator
> restarts...

It's already not the case since it's currently the pid of the
translator.

> The ideal would be to derive it from the underlying Mach device somehow.

Not all storage are Mach devices.

> The question is how to derive it if there's some sort of transformation
> involved, e.g. gzip stores, concatinated stores, unionfs, etc.  We'd need
> to find some stable algorithm that can produce fairly unique numbers.

That's why pids are quite neat.

> > - 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.

> 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).

> 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 would more accuratly depict the situation and wouldn't noticably
> affect performance, and we wouldn't have this confusion.

Yes.

Samuel