question about reservation and persistent reservation

Ming Zhang blackmagic02881 at gmail.com
Tue Jan 2 07:24:04 PST 2007


* From the T10 Reflector (t10 at t10.org), posted by:
* Ming Zhang <blackmagic02881 at gmail.com>
*
Hi George
On Tue, 2007-01-02 at 09:12 -0600, George Penokie wrote:
> 
> Ming, 
> 
> Reservations (not persistent reservations) were defined long before
> that was any such thing as multiple port devices and as such is not
> well suited for use is such environments. That is one of the reasons
> reservations no longer defined in the current SCSI specifications and
> were replaced with persistent reservations. 
make sense. we guessed it is too old to fit today's world.
> 
> In the process of defining persistent reservations is was not clear in
> the standards as to what the reservations were associated with. At the
> same time the SCSI architecture was moving from a parallel based
> architecture to a serial based architecture. That change required a
> clear delineation between ports and devices that was not previously
> necessary. The end result is that the I_T nexus became a port to port
> definition and that made all reservations port to port. 
> 
> I would suggest the only reasonable solution is the use of persistent
> reservations in environments that contain multi-ported SCSI devices. 
but if all reservations (even persistent reservation) port to port, then
this issue is still not solved in a reasonable way, why a target should
reject a request from _same_ initiator who holds reservation but
different port?
even the reservation key is to identified the _only_ nexus and can not
be borrowed by another nexus between _same_ initiator and target right?
>   
> Bye for now,
> George Penokie
> 
> Dept 9A8 030-3 A410
> E-Mail:    gop at us.ibm.com
> Internal:  553-5208
> External: 507-253-5208 
> 
> 
> Ming Zhang
> <blackmagic02881 at gmail.com> 
> 
> 01/02/2007 08:38 AM 
>	   Please respond to
>      blackmagic02881 at gmail.com
> 
> 
> 
> 
>		 To
> George
> Penokie/Rochester/IBM at IBMUS 
>		 cc
> Arne Redlich
> <agr at powerkom-dd.de>, Juhani Rautiainen <jrauti at iki.fi>, owner-t10 at t10.org,
"Ross S. W. Walker" <rwalker at medallion.com>, Steffen Plotner
<swplotner at amherst.edu>, t10 at t10.org 
>	    Subject
> Re: question
> about reservation
> and persistent
> reservation
> 
> 
> 
> 
> 
> 
> 
> 
> Hi George
> 
> Thanks for answering my question.
> 
> >From iSCSI RFC (http://www.faqs.org/rfcs/rfc3720.html)
> I_T nexus: According to [SAM2], the I_T nexus is a relationship
>     between a SCSI Initiator Port and a SCSI Target Port.  For iSCSI,
>     this relationship is a session, defined as a relationship between
>     an iSCSI Initiator's end of the session (SCSI Initiator Port) and
>     the iSCSI Target's Portal Group.	The I_T nexus can be identified
>     by the conjunction of the SCSI port names; that is, the I_T nexus
>     identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI
>     Target Name + ',t,'+ Portal Group Tag).
> 
> Why? In iSCSI, if one iSCSI initiator setup 2 or more sessions with
> _same_ target, i could not see any negative effect that commands can
> not
> send through all sessions to same target from same initiator.
> 
> Or one step ahead, when SCSI spec is defined, why reservation need to
> be
> nexus based (between initiator port and target port), not between
> initiator and target, for multiple port situation?
> 
> Ming
> 
> 
> On Tue, 2007-01-02 at 08:27 -0600, George Penokie wrote:
> > 
> > Ming, 
> > 
> > Reservations and persistent reservations are both I_T nexus based.
> The
> > question that has to be answered is; What has the iSCSI protocol
> > defined as the initiator port (i.e., the I) and the target port
> (i.e.,
> > the T). From SAMs point of view as long as the connection is between
> > the same I and T that holds the reservation then the command is
> valid
> > regardless of the actual physical path that is used (i.e., there can
> > be any number of physical paths between a single initiator port and
> a
> > single target port). 
> > 
> > Bye for now,
> > George Penokie
> > 
> > Dept 9A8 030-3 A410
> > E-Mail:    gop at us.ibm.com
> > Internal:  553-5208
> > External: 507-253-5208 
> > 
> > 
> > Ming Zhang
> > <blackmagic02881 at gmail.com> 
> > Sent by: owner-t10 at t10.org 
> > 
> > 12/28/2006 10:21 AM 
> >	     Please respond to
> >	 blackmagic02881 at gmail.com
> > 
> > 
> > 
> > 
> >		   To
> > t10 at t10.org 
> >		   cc
> > Arne Redlich
> > <agr at powerkom-dd.de>, Juhani Rautiainen <jrauti at iki.fi>, Steffen
> Plotner <swplotner at amherst.edu>, "Ross S. W. Walker"
> <rwalker at medallion.com> 
> >	      Subject
> > question about
> > reservation and
> > persistent
> > reservation
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > * From the T10 Reflector (t10 at t10.org), posted by:
> > * Ming Zhang <blackmagic02881 at gmail.com>
> > *
> > Hi All
> > 
> > We try to add reservation support to an iSCSI target and have some
> > questions about reservation.
> > 
> > Reservation is per nexus or per initiator? persistent reservation is
> > per
> > nexus or per initiator?
> > 
> > Our dilemma is like this. between an iSCSI initiator and target,
> > multipath IO can (1) has multiple sessions over to same target via
> > different physical NICs and paths. or (2) has one session with
> > multiple
> > connections, with each connection over different paths. Base on
> iSCSI
> > RFC, (1) will have multiple I_L nexus while (2) only have 1 nexus.
> > 
> > Then for reservation support via RESERVE_6/10, if one initiator
> > reserve
> > one LU via one session, can this initiator send WRITE or other
> > commands
> > via another session?
> > 
> > 
> > Thanks
> > 
> > Ming
> > 
> > 
> > *
> > * For T10 Reflector information, send a message with
> > * 'info t10' (no quotes) in the message body to majordomo at t10.org
> > 
> -- 
> http://blackmagic02881.wordpress.com/
> 
> 
-- 
http://blackmagic02881.wordpress.com/
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list