CODEWITHSUNDEEP
scsiiscsi
Ahmed A
Ahmed A

Reputation: 3652

SCSI persistent reservation in iSCSI

In iSCSI, the initiator port Id is defined as: iSCSI_Name,i,Initiator_Session_Id

And target port id is defined as: iSCSI_Name,t,Target_Portal_Group_Tag

After an initiator issues a "PR In - Reserve" SCSI command, the above info pertaining to an I_T nexus is persistently saved. If there happens to be a crash on the server, and after the initiator logs back in, the initiator will most likely get a new Initiator_Session_Id. If so, how will the initiator (or any initiator that is registered) clear the reservation?

Thank you, Ahmed.

Upvotes: 2

Views: 2056

Answers (1)

Mike Andrews
Mike Andrews

Reputation: 3206

If the "crash on the server` is a crash of the target side, then the iSCSI initiator will typically re-establish the session using the same session ID. The Linux and Windows initiators behave like this. A great part of the resiliency of iSCSI lies in its ability to recover session state independently from the transport protocol. In this case, it is not necessary to clear the reservation; the initiator retains it.

If the crash is on the initiator side, then you're right, unless the session is persistently recorded (on Linux, it's not), the session gets a new session ID. At this point, this is where the PERSISTENT RESERVE OUT - PREEMPT or PREEMPT AND ABORT commands come in. Clusters that use persistent reservations as a way of coordinating access to shared storage all have to deal with the case where you need to take over a reservation held by another initiator. This is what an SPC-4 draft says about the commands:

An application client may preempt the persistent reservation with another persistent reservation by issuing a PERSISTENT RESERVE OUT command with PREEMPT service action or PREEMPT AND ABORT service action with the following parameters:

a) RESERVATION KEY field set to the value of the reservation key that is registered with the logical unit for the I_T nexus;

b) SERVICE ACTION RESERVATION KEY field set to the value of the reservation key of the persistent reservation to be preempted; and

c) TYPE field and SCOPE field set to define a new persistent reservation. The SCOPE and TYPE of the persistent reservation created by the preempting I_T nexus may be different than those of the persistent reservation being preempted.

Here, your initiator would come up, and execute a PERSISTENT RESERVE OUT - REGISTER command to register its nexus. Then, it calls PERSISTENT RESERVE IN - READ RESERVATION and READ KEYS or perhaps just READ FULL STATUS to retrieve the key for the initiator that holds the reservation. Finally, it executes PREEMPT AND ABORT to move the old reservation over to its new nexus.

Source: (registration required) http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r35a.pdf (If you search around the web for spc4.pdf, you'll no doubt find a registration-free variation.)

Upvotes: 1

Related Questions