Subject: FW: SPC-4: Reporting SPC-2 Reservation Holder Date: Wed, 3 Sep 2008 06:04:56 -0700 From: "Raymond Gilson" <raymond_gilson@symantec.com> To: <t10@t10.org> X-Message-Number: 9072 Formatted message: HTML-formatted message ________________________________ From: Raymond Gilson Sent: Friday, August 29, 2008 11:05 AM To: 'Kevin D Butt' Subject: RE: SPC-4: Reporting SPC-2 Reservation Holder 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... ________________________________ From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf Of Kevin D Butt Sent: Monday, August 25, 2008 3:57 PM To: t10@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 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/