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@xxxxxxxxxxxx] > Sent: Thursday, January 29, 2004 1:31 PM > To: Smart, James > Cc: Philip R. Auld; 'Patrick Mansfield'; Simon Kelley; SCSI Mailing > List; dm-devel@xxxxxxxxxxx > 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 > >