On Sep 25, 2007, at 7:09 PM, Richard Elling wrote:
Dale Ghent wrote:
On Sep 25, 2007, at 7:48 PM, Richard Elling wrote:
The problem with this is that wrong information is much worse
than no
information, there is no way to automatically validate the
information,
and therefore people are involved. If people were reliable, then
even
a text file would work. If it can't be automatic and reliable, then
it isn't worth doing.
I dunno if I think we have to think this far into it.
Consider the Clearview project and their implementation of vanity
names for network interfaces. Conceivably, such a feature is
useful to admins as they can set the name to be a particular vlan
number, or the switch/blade/port where the other end of the
ethernet line is terminated. Or their ex-girlfriend's name if
it's a particular troublesome interface. The point is, it allows
arbitrary naming of something so that the admin(s) can associate
with it better as an object. Most importantly, there's a
distinction here. Solaris provides the facility. It's up to the
admin to maintain it. That's as far as it should go.
Actually, you can use the existing name space for this. By default,
ZFS uses /dev/dsk. But everything in /dev is a symlink. So you could
setup your own space, say /dev/myknowndisks and use more descriptive
names. You might need to hack on the startup service to not look at
/dev, but that shouldn't be too hard. In other words, if the answer
is "let the sysadmin do it" then it can be considered solved. The
stretch goal is to make some sort of reasonable name service. At
this point I'll note the the FC folks envisioned something like that,
but never implemented it.
# ramdiskadm -a BrownDiskWithWhiteHat 150m /dev/ramdisk/
BrownDiskWithWhiteDot
# zpool create zwimming /dev/ramdisk/BrownDiskWithWhiteDot
# zpool status zwimming
pool: zwimming
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE
CKSUM
zwimming ONLINE 0
0 0
/dev/ramdisk/BrownDiskWithWhiteDot ONLINE 0
0 0
errors: No known data errors
# ls -l /dev/ramdisk/BrownDiskWithWhiteHat
lrwxrwxrwx 1 root root 55 Sep 25 17:59 /dev/ramdisk/
BrownDiskWithWhiteDot -> ../../devices/pseudo/
[EMAIL PROTECTED]:BrownDiskWithWhiteDot
# zpool export zwimming
# mkdir /dev/whee
# cd /dev/whee
# ln -s ../../devices/pseudo/[EMAIL PROTECTED]:BrownDiskWithWhiteHat
YellowDiskUnderPinkBox
# zpool import -d /dev/whee zwimming
# zpool status zwimming
pool: zwimming
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zwimming ONLINE 0 0 0
/dev/whee/YellowDiskUnderPinkBox ONLINE 0 0 0
errors: No known data errors
-- richard
But nobody would actually do this. If the process can't be condensed
into a single step (e.g. a single command), people won't bother.
Besides, who would take the chance that a 'boot -r' would keep their
elaborate symbolic link tree intact? I wouldn't.
I've learned that you can't count on anything in /dev remaining over
'boot -r', patches, driver updates, san events, etc.
-----
Gregory Shaw, IT Architect
IT CTO Group, Sun Microsystems Inc.
Phone: (303)-272-8817 (x78817)
500 Eldorado Blvd, UBRM02-157 [EMAIL PROTECTED] (work)
Broomfield, CO 80021 [EMAIL PROTECTED] (home)
"When Microsoft writes an application for Linux, I've won." - Linus
Torvalds
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
