On 9/25/07, Gregory Shaw <[EMAIL PROTECTED]> wrote: > > > > 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 > >
I've actually contemplated requesting such a feature for /dev (creating vanity aliases that are presistant) as it would also be useful for things like databases that use raw disk (i.e. Oracle ASM). _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
