Re: disk naming proposal & devfs
Richard Gooch (rgooch@atnf.CSIRO.AU)
Mon, 12 Jan 1998 10:59:58 +1100
Larry McVoy writes:
> : What happens if I have the following:
> : /dev/sda5 /home
> : /dev/sdb1 /home/group1
> : /dev/sdc1 /home/group2
>
> /dev/home -> /dev/sda5
> /dev/group1 -> /dev/sdb1
> /dev/group2 -> /dev/sdc1
>
> And before you get all worked up because people can mount on /disk1/usr
> and /disk2/usr, add something like /dev/disk1!usr -> /dev/whatever,
> much like you suggested. In my 15+ years of Unix experience, there
> aren't a lot of name space conflicts on the basename of mount points.
> It's not an issue since you can support both basename and full pathname
> with "/"s translated to "!".
>
> : I don't see how this could possibly work. If I haven't yet mounted
> : /usr, how can the system know what /dev/usr is (in your naming
> : scheme)?
>
> The system probes each block device. It can just as easily read the super
> block (if there is one) on each block device. Most (all?) super blocks
> store the mount point that this file system was last mounted on. So you
> could just as easily have the boot up messages print out:
>
> SCSI device sda: hdwr sector= 512 bytes. Sectors= 2110812 [1030 MB] [1.0 GB]
> sda: sda1 (/) sda2 (/usr)
> SCSI device sdb: hdwr sector= 512 bytes. Sectors= 4194058 [2047 MB] [2.0 GB]
> sdb: sdb1 (/home) sdb2 (swap) sdb3 (/u)
>
>
> : > As far as I know, no other Unix system (or VMS/NT for that matter) has
> : > such a system. IRIX did something like this (has a /dev/root symlink)
> : > but I don't think it is used to mount the file system, it is made after
> : > booting up.
> :
> : That's because you have a chicken and egg problem :-)
>
> No, I don't.
>
> : Er, hold on. I think I see more what you're trying to do. You want to
> : move /etc/fstab elsewhere, essentially. So each FS/partition will
> : record where it should be mounted?
>
> Kind of, yes. The physical device names in fstab /may/ be replaced
> with logical names. The logical names are stored in the data and the
> system figures out the logical to physical mapping for you. The mapping
> is stashed in /dev by devfs (or something) and the system can happily
> use them /no matter where the partition happens to be today/. So the
> physical name part of fstab is indeed moved - to the devices themselves.
> Think of it as a distributed database of sorts.
>
> Just to beat a dead horse: The location of the data is stored in the data.
> Think of each disk partition as a "volume". Each volume has a type
> (file system, swap, unknown). Each volume of type "filesystem" has a
> superblock. Each superblock has a field, sb_lastmounted, which is the
> location where this partition was last mounted. When the system probes,
> it remembers all the block devices that were there, and then goes through
> another, higher level probe, where each file system is called to identify
> the block device's location. So this is a new fs operation, something
> like fs_mountpoint().
OK, well, I think this is not a problem for devfs. Once you have your
fs_mountpoint() you can simply call devfs_register(). So, submit a
patch and wait for it to be accepted (or shot down:-).
Regards,
Richard....