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
