UUID=3e6be9de-8139-11d1-9106-a43f08d823a6 /boot ext2 noauto 0 0
Regarding the above: not a good idea as it stands.
It's probably easier to mistype a lengthy [humanly-] unintelligible number
than cross two cables.
I would prefer to see:
/dev/somedisk /boot ext2
noauto,uuid=3e6be9de-8139-11d1-9106-a43f08d823a6 0 0
or
/dev/somedisk /boot ext2 noauto,label=boot 0 0
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.
As far as devfs is concerned, I think it addresses many issues. For those
"this is a user-space issue"
people who advocate /proc/dev/.... and read the information out with
scripts/a daemon, consider:
If you're going to publish the information anyway, why not put it in the
right place first time?
I agree that _adapter_ information should go in /proc - they have io/irq
data etc, but _disks_ go in /dev.
Devfs offers a very good, logical interface. It's tidy (no wasted entries,
no node creation. Believe me,
/dev on *big* unix systems [AlphaServers, 100+ disks, FibreChannel,
individually addressed by LUN]
is exceptionally messy.). It's even human-readable to boot. On how you deal
with persistance of
ownership/mode over reboot, I have no comment. That's probably a site-issue.
Symlinks, too, to
name devices according to _your_ preference, are a site-issue.
However, for NFS purposes, I prefer the idea of numbers, not names. The
client does not need to know
the actual physical location (in a disk rack) of the disk - that's a server
issue. It just needs a reference,
a "device descriptor" if you like. A major/minor system here is clearly
easier, but a _human_ need not
have to deal with these on a filesystem.
Ian Woodhouse (ian.woodhouse@hyder.com)
Hyder IT Unix Systems (x45109)
07775 533594 (mobile)
01656 765109 (direct)
-
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/