Date: Wed, 06 Oct 1999 11:37:31 -0400
From: Alex Nicolaou <anicolao@mud.cgl.uwaterloo.ca>
"Theodore Y. Ts'o" wrote:
> I claim that there are better interfaces than readdir() +
> stat() and a dynamic filesystem in order to pass this information to
> userspace, though, and I hope most people would agree with me. Why
> don't we try to design that interface first, and I suspect the rest will
> follow relatively easily.
Can you propose a better interface? I don't really understand your
comment, because the UNIX filesystem has always been the namespace
for operating system objects....
If we posit that in the long-term, we *have* to have a user-space
component to solve the dynamic /dev problem --- that trying to do things
like keep track of USB topology in a file or database in kernel space is
madness, etc. --- then readdir() + stat() is not the right interface.
It's a very inefficient way to get necessary information to the
user-mode daemon!
A much better interface for getting the information out to the daemon in
one fell swoop would be something like /proc/devices (except we would
want to list the minor and major mode devices). There would also need
to be an interface where a user-mode daemon could be informed of
changes; some kind of synthentic file which the daemon could select() or
poll(), and read() from to find new devices. Surely this is better than
forcing the daemon to periodically run readdir() over all of /devfs
looking for new devices!
Note that once the daemon has the information, it can do anything it
wants with it. For example, if having a clean /dev directory is the
holy grail for some people (it isn't for me, but different strokes for
different folks), a user-mode solution can be configured to do this as
well as provide for user/group/permissions persistence: the daemon would
simply have to stat() the device, store the information in some kind of
file or database, and then rm the device node. The point is that it's
infinitely more to do things in user-mode than in kernel mode.
Different people can write or modify the own user-mode daemon much more
easily, depending on their religion about how they want to maintain
/dev --- and if nothing else, this discussion has definitely shown that
there are lots of different opinions about what's the Best Way to manage
the /dev directory!
Date: Fri, 8 Oct 1999 03:04:43 -0700 (PDT)
From: Dan Hollis <goemon@sasami.anime.net>
> UUID-based mounting comes to mind. And it already works.
This only applies to filesystems with UUID. What about filesystems without
them (eg iso9660)? What about tape drives?
Tape drives use a completely different name space already (/dev/staX).
As far as iso9660 filesystems, they do have volume labels, as do most
filesystems, and you can always do mounts based on labels. With ext2
you can do things both ways:
LABEL=temp /tmp ext2 defaults 1 2
UUID=3a30d6b4-08a5-11d3-91c3-e1fc5550af17 /usr ext2 defaults 1 2
The advantage of doing things like this is that this makes mouting
devices independent even of the SCSI ID! You can re-arrange the SCSI
ID's, or if you're using JAZ cartridges, with a series of JAZ drives,
put the removeable cartridges any one of the JAZ drives, and have the
Right Thing Happen.
Another example of my mounting by volume label (which Solaris's vold
does, by the way), is if you have a jukebox of CD-ROM players. No
matter into which drive you insert a particular CD-ROM, it will get
mounted in the right place because vold consults and internal database,
and given a specific label the CD-ROM will get mounted in the right
place. (There's also a default where if the CD-ROM isn't yet in the
database, it will get mounted into some location based on the volume
label.)
Date: Thu, 7 Oct 1999 19:43:45 -0500
From: Grant Erickson <grant@lcse.umn.edu>
Take for example, a switched Fibre Channel fabric configuration (such as
the one here at the University of Minnesota which changes VERY often
during develoment and test work). The Fibre Channel standard allows:
239 switches per fabric, 255 ports per switch, 126 devices per port
Even accounting for interswitch links, that's about 7.6 million disk
drives (or other devices) that could, in theory, be connected to one host.
Those drives can move from one switch port to another switch port or from
one switch to another switch on the fly. Further, the topology of the
fabric can change on the fly. A device naming and allocation system which
accounts for this would be great. Neither Solaris nor Irix handle this
right now, it'd be nice if Linux could handle it whatever the solution
finally is.
You're talking about a Storage Area Network (SAN) here, and it's not
clear to me that a SAN is ever going to be best exposed as devices in
/dev, no matter whether /dev is static or dynamic. A SAN is much more
like a network, and just as putting all the hosts in the Internet into a
directory that might be exporting NFS filesystems and expecting "ls" to
work is probably not realistic, I don't think trying to put all of the
disks attached to a SAN on a directory is all that realistic either.
IMO, in the long term, SAN disks will want to be named by UUID, and the
filesystem layer is going to have to manage which disks together make up
a particular filesystem, and some kind of named-like name service daemon
how to find a particular disk, since we *do* want to be able to handle
moving the disks around (for example, when a disk is moved from Los
Alamos to Sandia, assuming that the SAN fabric has long-distance
encrypted links between Los Alamos and Sandia National Labs --- to use
an example from last month's Scalable Global Parallel Filesystem
Workshop in Santa Fe).
- 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/