Subject: [Ips] Question about iSCSI 3rd party reservation.

From: "Javen.Wu" <[email-masked]>
Date: Wed, 17 Aug 2005 05:09:43 +0800

Hi guys,
>3d party reservation is mandatory implement in SPC3.
> In fact, I want to know how the 3rd party reserve work for iSCSI.
> U know, if application wanna issue a 3rd party reservation. he will 
> birng a  3rd party device ID in CDB.
> How to translate the 3rd party ID to a real node name?
> I suspect if a parellel SCSI user wanna issue a 3rd reservation, he will 
> fill Target ID to the 3rd device ID field.
> And if a FC user wanan issue a 3rd reservation, he will fill WWN to the 
> 3rd device ID field.
> So I guess if a iSCSI user wanna issue 3rd reservation, the CDB of 
> reserve(10) will bring iqn name.
> I am not sure my guess is correct,just a guess.
> 
> Your reponse is appreciated. I just wanna discuss SCSI protocol implementation 
> in iSCSI target emulation.
> Thx again!
> BR
> Javen

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

---

From: William Studenmund <[email-masked]>
Date: Wed, 17 Aug 2005 10:00:36 -0700

>> 3d party reservation is mandatory implement in SPC3.

As Bill noted, this statement is incorrect.

What is correct is that, according to SPC2, if you implement the 
RESERVE(10) command, you also must implement 3rd party reservations.

>> How to translate the 3rd party ID to a real node name?

You don't. And that's the problem with RESERVE(10).

>> I suspect if a parellel SCSI user wanna issue a 3rd reservation, he 
>> will fill Target ID to the 3rd device ID field.
>> And if a FC user wanan issue a 3rd reservation, he will fill WWN to 
>> the 3rd device ID field.

Technically the WWN is in the parameter list, which is transfered as 
part of the data phase. But you are correct that the command should 
carry the iqn name. And the problem with RESERVE(10) is that the 
parameter list can only be 8 bytes, which won't fit an iqn name.

And that's why our (Wasabi's) target does not implement RESERVE(10) & 
RELEASE(10). It will never work right.

>> Your reponse is appreciated. I just wanna discuss SCSI protocol 
>> implementation in iSCSI target emulation.
>> Thx again!

---

From: Ming Zhang <[email-masked]>
Date: Thu, 18 Aug 2005 11:08:15 -0400

then how can u support those cluster service?

ming

---

From: William Studenmund <[email-masked]>
Date: Thu, 18 Aug 2005 08:34:59 -0700

> then how can u support those cluster service?

RESERVE(6)/RELEASE(6) and Persistent reservations.

Take care,

Bill

---

From: Ming Zhang <[email-masked]>
Date: Thu, 18 Aug 2005 12:29:42 -0400

:P yes, i forgot u can support RR6 only instead of RR10.

thanks!

Ming

---

From: Ming Zhang <[email-masked]>
Date: Thu, 18 Aug 2005 12:31:03 -0400

yes, u are right.

but my understanding is that new Persistent reservation in/out is a
super set of rr.

ming

On Thu, 2005-08-18 at 23:38 +0800, Javen.Wu wrote:
> Please refer to SPC3 revision 23 Annex B. Persistent reservation can 
> replace RESERVE/RELEASE functionality.
> Ming Zhang wrote:
>

---

From: William Studenmund <[email-masked]>
Date: Thu, 18 Aug 2005 18:39:49 -0700

On Aug 18, 2005, at 4:54 PM, Javen.Wu wrote:

> William Studenmund wrote:
>
> As my understanding about Persistent reservation, We need use a unique 
> identification for each I-T nexus.

My understanding is you need the same thing for the older reservation 
systems too. Note that according to SPC2, Reserve/Release reservations 
persist until released or the target is reset. Thus session 
reinstatement will not tear them down and you will have the same 
identification issues.

> In iSCSI area, what identification was used for I-T nexus?
> Session is I-T nexus in iSCSI concept. So SSID can identify iSCSI I-T 
> nexus.

Not only can it, but that's what is SHOULD do.

> SSID is composed by ISID and TSIH. However, I am wondering if the SSID 
> can identify I-T nexus for persistent reservation.

Why would the SSID not be able to identify an I-T nexus for a 
persistent reservation?

No, TSIH is not part of the SSID. The SSID is "(iSCSI Initiator Name + 
'i' + ISID, iSCSI Target Name + 't' + Portal Group Tag)." While TPGT 
and ISID are in there, they are not all that's there.

> I've read  some software iSCSI initiator implementation. I think it is 
> possible for two host have same ISID.

While they can have the same ISID, they should have separate 
InitiatorName values, so they will be separate I_T nexuses.

> So I suspect iSCSI target have responsibility to make TSIH unique. 
> Otherwise, how to make sure which session is take the owner 
> persistently.

No. There is no ambiguity here, and the target certainly shouldn't try 
to cook TSIH to differentiate different initiators. TSIH really is more 
of a versioning of a session as seen by the target. It is used to make 
sure that both the initiator and target are agreed as to what version 
of a session instance is currently operating. If the initiator tries to 
join a session (I_T nexus) but uses the wrong TSIH, the target knows 
either to reject the login attempt (attempt to join old/invalid 
session) or to trigger session reinstatement (initiator rebooted and is 
trying to login again).

For TSIH to work like that, SSID needs to not change; if the SSID is 
different, we're talking about different I_T nexuses, so you can't 
compare TSIH values between them.

Take care,

Bill

---

From: "Javen.Wu" <[email-masked]>
Date: Thu, 18 Aug 2005 23:38:14 +0800

---

From: "Javen.Wu" <[email-masked]>
Date: Fri, 19 Aug 2005 07:54:34 +0800

Session is I-T nexus in iSCSI concept. So SSID can identify iSCSI I-T nexus.
Otherwise, how to make sure which session is take the owner persistently.

Best Regards
Javen