Re: grub vs st_dev (aka fsid) / st_rdev

[Carl Fredrik Hammar]

Hi,

On Mon, Nov 09, 2009 at 10:47:08PM +0100, Samuel Thibault wrote:
> I can see two solutions:
> 
> - Either we align more on POSIX to manage to get the st_dev (aka
>   fsid) of filesystems equal to the the st_rdev of their underlying /dev
>   entries.  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.  It would be nice if the fsid was acctually stable
accross translator restarts...

The ideal would be to derive it from the underlying Mach device somehow.
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.

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

I think it would be better if the range was encoded in a seperate store
with the device as a child store.  This would more accuratly depict the
situation and wouldn't noticably affect performance, and we wouldn't
have this confusion.

Regards,
  Fredrik