[dm-devel] RE: Is there a grand plan for FC failover?

[Smart, James]

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 at 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 at 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
> 
>