Messages in this thread | | | Date | Mon, 12 Jan 1998 10:59:58 +1100 | From | Richard Gooch <> | Subject | Re: disk naming proposal & devfs |
| |
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....
| |