RE: Is there a grand plan for FC failover?

Smart, James
2004-01-29T19:38:17Z

I agree with what's here. Some of my concern did come from trying to support
older SCSI-2 devices, or some of those implementations before Persistent
Reserve finally settled to where it is now, and how you actually detect the
different rev/behaviors.

IMO - After addressing the semantics of the reservations types and how to
identify what's what(which is all SCSI-based) - why isn't this in the scsi
layer ? Pushing this up a level to a transport agnostic layer seems to just
impose more behaviors on that layer, and create a bunch of new interfaces
for what SCSI could already know/do. Also, when considering the timing
constraints and ownership issues pushing this to user land doesn't seem
right either.

-- James S

> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@SteelEye.com]
> Sent: Thursday, January 29, 2004 1:31 PM
> To: Smart, James
> Cc: Philip R. Auld; 'Patrick Mansfield'; Simon Kelley; SCSI Mailing
> List; dm-devel@sistina.com
> Subject: RE: Is there a grand plan for FC failover?
>
>
> On Thu, 2004-01-29 at 12:35, Smart, James wrote:
> > Why do you imply that you're down to a single path ? With
> multiple port
> > devices, and the T10 unclarity on multiport support, simple
> reservations
> > didn't bring you down to the single port access you are
> describing. Some
> > devices may have implemented it this way, but the standard
> didn't say they
> > had to or even that they should.
>
> T10 implies SCSI-2 reservations protect single paths. Any multi-port
> SCSI-2 reservation implementations tend to be vendor
> specific. That's a
> nasty I don't think we want to get into.
>
> > And this picture changes significantly with the use of Persistent
> > Reservations and the use of keys.
>
> That's the point, it doesn't. T10 clarified the persistent
> reservation
> holder (5.6.2.6 in rev 16) so that it's a specific I_T nexus (which is
> effectively a specific path unless you have fabric redundancy) except
> for all registrant reservations (which aren't useful for clustering).
>
> Obviously, this seems to require that the reservation be held against
> everyone when the port switches, which would preclude doing user level
> reservation handling, hence the need for a separate ownership API
> (assuming all vendors get on the same page about this).
>
> James
>
>