I would prefer to see:
and use the uuid/label as a check, not a mechanism for mounting.
Remember that /etc/fstab also documents to the _human_ sysadmin which disk
is used where.
That is, "/dev/scsi/c0t0d0..." relates to a physical position within a disk
rack; a uuid does not.
The problem is that you want to mount the filesystem in the same place,
even if the SCSI ID changes. For example, what happens if you insert a
new SCSI controller and so what was previously SCSI controller #0 is now
SCSI controller #1? That's why it's better to reference filesystems to
be mounted by UUID's instead of by SCSI ID #'s. Ideally, the system
shouldn't refuse to boot just because you've inserted a new SCSI
controller.
Obviously, you don't want to force the user to enter the UUID by hand;
there needs to be a good set of tools that do all of this automatically
for the user. But what should be stored should be the UUID.
At some level, that's why I don't like devfs; it doesn't do enough, and
at the same time it does too much (it puts too much policy into the
kernel --- namely the device names, which is somethign the kernel should
be agnostic about).
The real right solution requires writing a user-mode daemon which gets
informed by the kernel when interesting events happens, and then Does
The Right Thing. Solaris's vold is an interesting example of such a
user-mode daemon, although it doesn't do everything right. (And it
doesn't handle the device naming, although Solaris uses a partial
user-mode solution to handle that piece of things too.)
Some of the argumenets made in the past for devfs (i.e., optimizing the
speed of opening a device file) are really bad reasons. Does anyone
really think that opening files in /dev is really something which
happens often enough that it should be optimized?!? Opening device
files simply isn't something that happens all that often, and I suspect
that the incremental speedup between the dcache and devfs is barely
measuarable.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/