[Iscsitarget-devel] A Question about SCSI-3 Persistent Reservations
Lee Duncan
As you may remember, I'm working on a patch to add support for type=7
and type=8 SCSI-3 Persistent Reservations to iscsitarget. These are the
newer "all registrants" type of reservations.
While working on this, I found what may be a bug, and I wanted to check
to see if anybody else has seen this, or if this is even a bug. My
reading of the SPEC is that it is a bug, but, not being a lawyer, I
sometimes doubt my interpretation of said SCSI SPEC.
The problem I found is with the concept of "reservation holder". I
believe the code incorrectly identifies the holder of a persistent
reservation in the response to the PRIN "read full status" service action.
Here's my simple test scenario: Two initiators and one target system.
The iscsi target disk is instantiated as "/dev/sdc" on both initiatiors.
First initiator registers with key "abc", second with "123".
First initiator reserves with type=3 (exclusive access).
Try to read from second initiator (e.g. "fdisk /dev/sdc"), and it will
fail, as expected. This verifies that the reservation actually works
correctly with respect to I/O.
But ... here's the problem ... run "sg_persist --read-full-status
/dev/sdc" from the first initiator, which prints out:
> IET VIRTUAL-DISK 0
> Peripheral device type: disk
> PR generation=0x2
> Key=0x123
> All target ports bit clear
> Relative port address: 0x1
> << Reservation holder >>
> scope: LU_SCOPE, type: Exclusive Access
> Transport Id of initiator:
> iSCSI name: iqn.2005-03.org.open-iscsi:58a396a62cc2
> Key=0xabc
> All target ports bit clear
> Relative port address: 0x1
> << Reservation holder >>
> scope: LU_SCOPE, type: Exclusive Access
> Transport Id of initiator:
> iSCSI name: iqn.1996-04.de.suse:01:e211bedfca93
This output is wrong. Note that it indicates the there are two
registrants, and each one seems to be the "Exclusive Access" reservation
holder! This cannot be, since exclusive in this case means exclusive to
one initiator session, so only one initiator can have the reservation.
If you run the same command from the other (second) initiator, i.e. the
one that did not reserve the device, it shows that *neither* initiator
has the reservation, which is also wrong.
The problem in the code seems to be in pr_in_read_full_status(), which
calculates the reservation "holder" using the function
pr_is_reserved_by_session(), but it passes in the session ID of the
current session when checking *each* registrant's lock ownership. It
should instead be comparing against the session ID for that initiator.
There is an easy fix for this, but I wanted to verify this is really a
problem before I incorporate submit a patch.
--
Lee Duncan
SUSE Labs
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Iscsitarget-devel mailing list
Iscsitar...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel
Ross S. W. Walker
This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.