Messages in this thread | | | Date | Fri, 8 Oct 1999 09:50:54 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: [linux-usb] Re: USB device allocation |
| |
[I've replied to a number of different people in one message, since I don't particularly like the fire-15-different-replies-for-each-message- found-on-thread style of debating which some poeple seem to have adopted. I've also not bothered responding to ad hominem attacks. -- Ted]
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/
| |