Subject: Re: Multi-path SCSI
To: Jason Thorpe <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 09/22/2004 10:09:40
Content-Type: text/plain; charset=us-ascii
On Tue, Sep 21, 2004 at 03:09:56PM -0700, Jason Thorpe wrote:
> However, I no longer think that's a good idea... there could be all=20
> sorts of synchronization issues if you wanted to try and load-balance=20
> traffic across the multiple paths. (This is even more fun with iSCSI=20
> ... you can have multiple connections within a single session in iSCSI,=
> with the session being the path, if I'm not mistaken...)
You are correct about iSCSI. You can have multiple (TCP) connections=20
within a single iSCSI session.
> Anyway, I think maybe something a little simpler than the scsi_vhci=20
> idea from Solaris could be good... basically, generalize the idea of=20
> multi-path in our SCSI mid-layer, and instead of a device simply=20
> pointing to a scsipi_channel, allow it to have a list of channel=20
> pointers, representing the individual paths. We could keep a global=20
> list of scsipi_periphs, and when a new one is found, do multi-path=20
> detection by scanning that list.
I agree with the idea of adding multi-path support into the SCSI layer. If=
we could stash all of this under sdX, excellent. I'm not sure what config=
magic is needed to, partway through attaching a scsi device, stop adding a=
new device and add an extra path.
Note: we have to do i/o on the device to figure out if it's an extra path.=
But then again we have to do i/o to figure out it's a disk, so that's not=
> Regarding the device name, my wedges implementation will take care of=20
> 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=20
> implementation) to create a device node in /dev that corresponds to the=
I love the level of naming and thus identifiers you are talking about. IDs=
better than "sd3" were my main objection to/concern with wedges. Cool!
I think the best thing would be to work the naa into the name. VPD page=20
0x83 has different binary names, and Windows requires one of the two naa=20
variants to pass WHQL testing. So I think all the disks for which we need=
to worry about this will have the right VPD.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----