lkml.org 
[lkml]   [1999]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.089 / U:1.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site