Subject: RE: [Ips] MPIO with Persistent Reserve Out/In

From: "Qi, Yanling" <[email-masked]>
Date: Wed, 20 Dec 2006 10:10:46 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 20, 2006 10:37 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Ips] MPIO with Persistent Reserve Out/In
> 
> > I can not find this from original rfc or the new guide draft about
how
> > MPIO work with Persistent Reserve Out/In or old Reserve/Release.
> >
> > In iSCSI, a session is a I_T nexus. With MPIO, then between one
> > initiator and one target will have multiple I_T nexus. If initiator
> > setup a reservation via 1st session, can it send out commands like
> write
> > via 2nd session? Intuitively, I think it should be able to.
> 
> No - if you want that behavior, use multiple TCP connections in a
single
> iSCSI session.
> 
> > But from SPC, reservation will base on I_T nexus so 2 sessions are 2
> > different I_T nexus.
> 
> That is how iSCSI behaves - no change to SPC.
> 
> Thanks,
> --David
[Qi, Yanling] Here is my 2 cents. The reservation management should be
much higher than the transport layer. I see different implementations
cross different MPIO implementations.
	1. Multipath service layer provides a scsi pass-through
interface for an individual I_T_L nexus. The application which manages
the reservations will use the interface to do registration/reserve I_T_L
nexus by I_T_L nexus. I saw one server vendor does it in this way.
	2. Multipath service layer takes care of the PR-IN/OUT
translation which is received from a virtual device to multiple I_T_L
nexuses. MS MPIO for LH takes this approach.
	3. Special device nodes for each I_T_L nexuses. Applications on
Linux can use /dev/sgX to perform reservation management. The device
mapper may just leave the reservation management responsibility to the
applications.

Thanks,

Yanling

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips