Messages in this thread | | | Date | Tue, 15 Jun 1999 15:21:08 +1000 | From | Richard Gooch <> | Subject | Re: UUIDs (and devfs and major/minor numbers) |
| |
tytso@mit.edu writes: > From: Woodhouse Ian <ian.woodhouse@hyder.com> > Date: Thu, 10 Jun 1999 11:47:07 -0000 > > 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.
The devfs patch includes a "scsihosts=" boot option which allows you to control SCSI host numbering.
However, I don't propose devfs as the final solution to the problem of moving discs. I think that UUIDs (with a friendly human interface) are a good idea.
On the other hand, the location-based naming scheme in devfs is very good for many installations, and more importantly, is easy to use on unlabelled partitions.
> 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.
I can accept that.
> 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 device names are really no more policy than device numbers. But having device names rather than magic numbers conveys a number of distinct advantages: - convenient and workable defaults - dynamic /dev, even at boot time - grouping of devices.
That last point is really worth considering. It allows you to find all devices of a certain type with a construct like: opendir ("/dev/ide/cd"); loop;
This handles module autoloading cleanly, and gives you an automatic 1:1 correspondence between FS entries and hardware devices.
> 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.)
Have a closer look at devfsd. This can do some really clever things that are only possible because of a virtual /dev.
I've tried to explain this before, but it seems to have been ignored. Devfs is very lightweight, and *does not* attempt to do everything in kernel space. What it does is enough to provide a minimum workable infrastructure which can then be very flexibly extended with devfsd.
Let me state that I agree with the principle of putting as much as possible in user space. Devfs follows that principle. I know it would be possible to push some of the functionality of devfs into user space, but that would then make some things very hard or impossible to do in user space. This is why I say devfs provides the minimum necessary. The really cool things are then easy to do with devfsd.
Really. Have a look at what you can do with devfsd. Think about the possibilities. Try to look past your resistance to devfs and look at what it actually does and how it does it.
One of the things that convinced me that devfs is a good idea is the way I've been able to do new and cool things with the infrastructure it provides. Things I'd never even thought of when I'd implemented it. Flexible designs strongly suggest good designs.
> 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.
Devfs doesn't speed up dcache accesses, because, like any other FS, devfs sits "underneath" the dcache. However, what it does do is avoid searching the major tables for the file operations when you open a device. As I've said, right now that is cheap because we have a simple table. With 12+ bit majors, we're not going to have a table, we're going to have a list. And as I've also said, searching (hashing) that list isn't going to be very expensive, but it is a pointless search that can easily be avoided. Cheaply. As part of a package that provides a bunch of more significant benefits.
Regards,
Richard....
- 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/
| |