FW: SPC-4: Reporting SPC-2 Reservation Holder

Raymond Gilson raymond_gilson at symantec.com
Wed Sep 3 06:04:56 PDT 2008

Formatted message: <A HREF="r0809030_f.htm">HTML-formatted message</A>

From: Raymond Gilson 
Sent: Friday, August 29, 2008 11:05 AM
To: 'Kevin D Butt'
Subject: RE: SPC-4: Reporting SPC-2 Reservation Holder
I think this is a great idea!
Typo in text for Table 8 (6.13.5), talks about SPC2_R set to one twice
-- the first time is should be set to zero.
Arrow 1:
I don't like to see fields conditionally defined as "undefined".  
The Key field can be set to zero, as that value isn't legal to register.
The Scope/Type fields are a bit nastier, as zero is already used, and
the Type fields are nearly all defined.  If you made them "zero", at
least the combination of the two would hit an "Obsolete" settings.
Perhaps "undefined" is the best way around this.
The PRgeneration field is addressed in the Arrow 2.
Arrow 2:
Increment the PRgeneration for each SPC-2 Reserve command that
establishes a reservation and for each SPC-2 Release command that
removes a reservation.	The PRgeneration is attempting to warn other
Initiators that something odd has happened to their
Registration/Reservation, or someone else has Registered.  None of these
odd things are important unless they have already Registered.  The SPC-2
commands cannot "work" in this case, so a few extra increments won't
cause anyone heartburn.
Arrow 3:
The Read Reservation should have a new set of parameter data for the
case of a SPC-2 reservation.  This could be a block of data with the
additional length set to 4.  The first byte following would include the
SPC2_R flag.  The three following bytes would be Reserved.  I'm sure a
Reserved bit could be found in the existing returned data block if a
third form isn't desired.
The Read Full Status doesn't report anything of particular value to an
application -- target port / transport information is unknown to them.
I would like to be able to use the Read Reservation command to find out
if a reservation exists or not.
Arrow 4:
The new form of Read Reservation (if created), and/or the Read Full
Status (if something isn't done about Read Reservation) must be
mandatory for any target that reports the PIRH bit as one.  It seems
that the text makes all of the defined service action codes mandatory (I
see "SHALL" return data for each).  MANY devices do not support any
service action code other than 0 and 1...
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Sent: Monday, August 25, 2008 3:57 PM
To: t10 at t10.org
Subject: SPC-4: Reporting SPC-2 Reservation Holder
I have uploaded a proposal for consideration of reporting the
reservation holder of an SPC-2 reservation (i.e., RESERVE(6) or
started this proposal it seemed like a quick and easy thing that could
be accomplished by simply defining a single new bit in the READ FULL
STATUS descriptor and everything would be perfect.  I was hoping to get
it through with only minor edits during CAP. 
Alas, this involves Persistent Reservations.  You should all know what
that means! (>_<)> 
It turned out to be a lot bigger than I anticipated. 
Any arrows you could send at me ahead of time would be appreciated. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com

More information about the T10 mailing list