General:
I think this is a great idea!
Blunt-Arrow:
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...
I have uploaded a proposal for
consideration of reporting the reservation holder of an SPC-2 reservation (i.e.,
RESERVE(6) or RESERVE(10)) using the PERSISTENT RESERVE IN - READ FULL STATUS.
When I 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.
http://www.t10.org/ftp/t10/document.08/08-342r0.pdf
Any arrows you could send at me ahead of time would be
appreciated.
Thanks,
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@us.ibm.com
http://www-03.ibm.com/servers/storage/