>
> On Tue, 28 Mar 2000, Matthew Jacob wrote:
>
> > Umm, okay. Is this with Veritas DMP or VCS?
>
> Good question. DMP I think. I'm not sure what VCS is.
Veritas Cluster Server
>
> > an active-active configuration. If you use Greg Lehey's VINUM in FreeBSD, I'm
> > not clear about what it's role in terms of recognizing redundant paths might
>
> There doesn't seem much point in using VINUM with an external RAID5 box
> (although we use VINUM a lot on other machines).
Well, you get volume (plex) identification out of it, which is of help when
you don't want to try and keep track of where disks end up over time manually.
> > identification restrictions that could cause an upset. The CAM midlayer does
> > track Vital Product Data (like drive serial numbers), but this is put together
> > with a bus address (e.g, HBA, bus on HBA, target, lun) to track whether
> > particular device has changed at that location or not- not whether that
> > particular spindle is replicated elsewhere.
>
> Would it be hard to add intelligence to this layer that would detect if a
> drive (via it's VPD info) is visible on multiple busses? If so is there a
> point in CAM where it could be modified to handle, at the minimum, a
> redundant path or better yet, use multiple paths to a device?
>
> The box to which I'm hooking this up has sufficient performance to handle
> 16 U2W SCSI links running hard. Being able to utilise multiple paths
> could be a big performance win.
You can indeed add intelligence, but it's a very wide open question how and
where the intelligence should be used. And the "why" is of importance as well.
You essentially need to coordiante object and path identification with volume
and filesystem usage.
Right now there's no problem about having multiple paths to the same disk- the
only piece that's really missing is some moderately easy method to export this
information out of any specific layer- but this isn't that hard to do, and
could, in fact, be done via a user daemon without any kernel modifications, so
I don't view this as a hard problem.
What's harder is *how* to use it. There are no particular hooks in FFS to
handle the multiple paths simultaneously with any coherency (for performance
reasons, should you want to do so and could prove that it'd be worthwhile),
nor are there any particular hooks that I'm aware of to do dynamic
multipathing for failover reasons at the volume or device level- if there were
in FreeBSD, I suspect VINUM in conjunction with a completed DEVVS might be the
place for them, but that's just random speculation on my part.
>
> > Absolutely. I mean, we do have a supported Fibre Channel card (Qlogic 2100 and
> > Qlogic 2200), but not as much testing as one would like.
>
> I have a Qlogic 2200 on order to test this out.
Good! You'll find that this is better with respect to full fabric support if
you happen to have, e.g., a Brocade switch on order.
>
> > You should note that there isn't, for fibre channel, any particular address
> > wiring enforced except by that which the target device does (e.g., if the
>
> Would this be similar to the situation that we had with FreeBSD before you
> could wire down devices?
Yes, somewhat, but not quite as bad.
>
> > Let me know if this is enough info to help.
>
> I'm getting a little beyond my depth in CAM internals here. But it is
> *very* interesting. :)
>
> Thanks,
You're welcome. Lemme know how it goes.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
