grub vs st_dev (aka fsid) / st_rdev

[Samuel Thibault]

Hello,

Currently, grub has no way to know which /dev/ entries corresponds to
/boot and /.  Its detection mechanism is to run stat /, which on Linux
notably gives

Device: 306h/774d       Inode: 2           Links: 29

i.e. st_dev is (3,6), and it also runs stats on /dev/*, notably
/dev/hda6:

Device: eh/14d  Inode: 6385        Links: 1     Device type: 3,6

i.e. st_rdev is (3,6) too, thus the match between / and /dev/hda6.

On GNU/Hurd, stat / gives

Device: 3h/3d   Inode: 2           Links: 24

i.e. st_dev is 3, that's the pid of ext2fs (aka fsid).

and stat /dev/hd0s1 gives

Device: 2f4eh/12110d    Inode: 33554       Links: 1     Device type: 0,0

i.e. st_rdev is always zero.  Mismatch.

A good thing in using the pid for the st_dev is that it's indeed unique
even if there are plenty of translators.  However, there is no relation
between the storeio process's st_rdev and the fs process's st_dev.  Even
worse, there is even less relation between the storeio process of / and
the / fs process since the latter doesn't talk to the former but to GNU
Mach.  The only link that POSIX seems to make between them is their
description: “dev_t st_dev Device ID of device containing file” and
“dev_t st_rdev Device ID (if file is character or block special).”

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.

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

Samuel