Date: Mon, 24 Jul 2000 14:40:19 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Jack Rusher <jar@integratus.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: SANs, disks, & devfs Message-ID: <Pine.BSF.4.05.10007241427230.15581-100000@semuta.feral.com> In-Reply-To: <397CABB4.1CAAC7C3@integratus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I think that vinum is already good, like VxVM also, in that once you label a > > disk (i.e., borg it into vinum), it's boot-time to boot-time address becomes > > can become less relevant. > > Yes, there is self descriptive meta data on VxVM and vinum drives. > However, you need some way to tell vinum which drives to eat. Okay- yeah, that's right.... > I think > it would be useful to be able to specify this in a WWN aware fashion. Sure- that'd make it like VxVM then. I sorta thought it was there already. > > > The whole /dev/dsk/XXX goop was/is a complete disaster in that it half-assed > > mushes together some bogus fixed name and address semantics into a symlink > > to try and give you some location info in the 'friendly' name (as opposed > > to the completely unambiguous physical pathname of the 'all-singing, > > There are some problems with trying to do this with WWN (or any other > serial number) as the only entry point to the device. Namely, you can't > be sure that the device will have any such serial number. Also, it > makes it a pain in the ass for the casual user if they can't just say > "/dev/da0, please." It wasn't meant to be exclusionary- just additive. And the WWN and VPD serial number are alternate methods, both possibly qualified by lun. The 128 bit WWN that you can get as page 0x83 *can* be per LUN, but all disk drives are currently 64 bit WWNs. > > I think that the constancy of the /dev/daX namespace is relevant only as > > long as that is the name in /etc/fstab. > > There are other issues having to do with what happens when you pull a > disk out and copy the contents onto another drive (upgrade to bigger > primary disk, for instance). You want to just stick the drive back in > the machine and have everything boot and work normally. This only works > if the fstab looks at the first SCSI drive by a positional name. Yes- of course. > > The other option is to use disklabels (instead of disk serial numbers) > to identify the disks. You can provide a label copy tool to clone a But you've fundamentally changed the object. It no longer is disk WWN XXXX- it's now disk WWN YYYY. You just happen to have ensured that the contents of YYYY or the same as XXXX. > disk, but you run into trouble when you have two disks that are clones > of one another in the same system. You also have trouble if one of the > disks is the Windows/Linux/whatever partition of your workstation and > has a label scheme that doesn't play nice with the BSD scheme. What do > you call that disk in the device tree? Exactly. That's the drawback of a label based scheme in some sense- which is why I want to use properties of the device that are immutable and irrespective of the data content. That doesn't mean that at a different point labels are not desirable! It's just that this is a different identification level. > > All I am trying to illustrate here is that there are some cases where > it is better to have absolute names and some cases where positional > abstraction is the right answer. It would be nice if we could have a > compromise of the two techniques that lets you look at your storage in > the way that makes the most sense for your application. Absolutely. At Sun, the take on it was that the devfs (derived from either an OBP prom tree or built via harwired root nexus and conf fragments for the original sun4 proof of concept) representation would be unambiguously physical, while /dev names would be logical. I argued that /dev/sd[0..n] was perfectly adequate in this model (rather than trying to encode position information into the name as the /dev/[r]dsk names do). Furthermore, naming disks (at least) by volume name (the "Fred" volume) is even more convenient. As you say- sometimes you want physical names. Sometimes you convenient logical. Physical names invariably end up being hard for anyone to use. Logical or convenient names aren't adequate to formally address a device without some under-the-hood magic to persistently get the right (current) physical address. This all has more immediacy than a 'would be nice' for me. One approach that Qlogic (and JNI) have taken with HBA drivers is to attempt to maintain a persistent 'target<>WWN/port' binding in card NVRAM. This allows that which was 'probed/logged in' as target 93 to stay target 93 even if it changes to a different loop position- also it gives the correct hint as to how to bind it if this is a fabric device. I *really* don't want to implement this for my *BSD/Linux Qlogic driver as this raises all sorts of other problematic issues. I'd much rather see some framework in FreeBSD (and NetBSD and OpenBSD.... Linux has a devfs going...) to accomodate this. But that isn't there yet and won't be for a while. I want to solve this for 5.0 for sure. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10007241427230.15581-100000>