Subject: Re: Multi-path SCSI
To: None <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 09/21/2004 15:09:56
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Sep 20, 2004, at 5:35 PM, Bill Sommerfeld wrote:
>> The question is what do we do if we find a match?
> Solaris copes with this by optionally reparenting fiber channel disks
> to a "virtual host controller" known as "scsi_vhci"; it also changes
> the device names from the merely unwieldy cNtNdN format to one where
> the "target" part of the device name is the world-unique value.
> IMHO, the former is one reasonable way to avoid having to turn the
> device tree into a less-constrained graph; the latter is a pain.
I was thinking about this, and discussing it with Bill (the other Bill
:-) when I suggested he post to tech-kern about it...
Initially, I was thinking this could be handled with "wedges" (which,
BTW, I have a prototype implementation of that I plan on posting about
shortly). My original idea is that you could simply have "multiple"
parents of a wedge (representing the various paths) rather than one.
However, I no longer think that's a good idea... there could be all
sorts of synchronization issues if you wanted to try and load-balance
traffic across the multiple paths. (This is even more fun with iSCSI
... you can have multiple connections within a single session in iSCSI,
with the session being the path, if I'm not mistaken...)
Anyway, I think maybe something a little simpler than the scsi_vhci
idea from Solaris could be good... basically, generalize the idea of
multi-path in our SCSI mid-layer, and instead of a device simply
pointing to a scsipi_channel, allow it to have a list of channel
pointers, representing the individual paths. We could keep a global
list of scsipi_periphs, and when a new one is found, do multi-path
detection by scanning that list.
Regarding the device name, my wedges implementation will take care of
that. Wedges have a "wedge name" in UTF-8, sort of like a volume name.
This wedge name could be used (and will be, eventually, in my
implementation) to create a device node in /dev that corresponds to the
-- Jason R. Thorpe <firstname.lastname@example.org>
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----