[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

grub vs st_dev (aka fsid) / st_rdev

From: Samuel Thibault
Subject: grub vs st_dev (aka fsid) / st_rdev
Date: Mon, 9 Nov 2009 22:47:08 +0100
User-agent: Mutt/1.5.12-2006-07-14


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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]