ALL_TG_PT clarification

Ralph Weber roweber at IEEE.org
Fri Feb 24 05:35:47 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Rich,
Rob is on vacation. He may have a different take on this than
I do, but it will not appear of this reflector for several days.
A device server is allowed to return CHECK CONDITION status with
ILLEGAL REQUEST sense key at any time it deems appropriate. Note
that ASC INVALID FIELD IN PARAMETER LIST is included in this rubric.
If SPC-x were to document every occasion where the ILLEGAL REQUEST
sense key could or should be used, the page count would double or
triple, but no substantial value would be added to the standard.
Obviously, SPC-4 contains plenty of exceptions to this philosophy.
Whether this case rises to the level of needing a change almost
certainly depends on the willingness of somebody to write a proposal.
All the best,
.Ralph
Rich Ramos wrote:
>
> Hey all (Ralph/Rob E. especially),
>
> I've got a clarification on something that looks like it's been 
> hanging around quite a while.
>
> In both SPC-3 and SPC-4, ALL_TG_PT is defined in 6.12.3 as being 
> optional but never says what to do if not supported by a device.  As a 
> comparative example, APTPL is in the following paragraph and 
> specifically calls out to return a check cond.
>
> I dug up the attached email from Rob E. back in '03 where he says that 
> it is *supposed* to return check cond:
> "If designed with SPC-3 knowledge, it is supposed to return INVALID 
> FIELD IN PARAMETER LIST."
> However, if it really is supposed to do that it must not have made it 
> into the spec, true?	Ralph or Rob care to comment for sure.
>
> -Rich
>
> ------------------------------------------------------------------------
>
> Subject:
> RE: Persistent Reservation question
> From:
> "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> Date:
> Fri, 13 Jun 2003 20:10:47 -0500
> To:
> "Ken Craig" <kcraig at istor.com>, <t10 at t10.org>
>
> To:
> "Ken Craig" <kcraig at istor.com>, <t10 at t10.org>
>
>
>* From the T10 Reflector (t10 at t10.org), posted by:
>* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
>*
>
>  
>
>>-----Original Message-----
>>From: Ken Craig [mailto:kcraig at istor.com] 
>>Sent: Thursday, June 12, 2003 1:08 PM
>>To: t10 at t10.org
>>Subject: Persistent Reservation question
>>
>>I have a question concerning Section 6.12.3,
>>PERSISTENT RESERVE OUT parameter list, in
>>revision 13 of SPC-3.  There are three
>>paragraphs that explain the meaning and usage
>>of the SPEC_I_PT, ALL_TG_PT, APTPL bits in
>>the parameter list.  The paragraphs for the
>>ALL_TG_PT and APTPL bits make specific mention
>>of the fact that the bits are to be ignored
>>for any Service Action but the two listed.
>>However there is no statement to the same
>>effect in the paragraph that describes the
>>SPEC_I_PT bit.  Is this an oversight or is
>>the setting of the bit considered to be
>>valid for all PERSISTENT RESERVE OUT Service
>>Actions?
>>    
>>
>
>There are two paragraphs that discuss SPEC_I_PT.
>
>The first is really the PARAMETER DATA LENGTH paragraph, noting that the
>length must be 24 if SPEC_I_PT is 0.
>
>The second, above table 107, is the main SPEC_I_PT paragraph.	It does
>mention that the additional parameter data, if present, is ignored
>(rather than saying the SPEC_I_PT bit is ignored).
>
>All three bits are mentioned in Table 108 (part 2), which marks them
>valid/ignored for the same service actions.
>
>  
>
>>Also, if the SPEC_I_PT or ALL_TG_PT bits are
>>set for the appropriate Service Actions but
>>the Target does not support the option should
>>the Target return the same error information
>>as it does for the APTPL bit being incorrectly
>>set?
>>    
>>
>
>If the logical unit was based on SPC-2, INVALID FIELD IN PARAMETER LIST
>would be returned by logical units that check reserved fields.  Nothing
>would be reported by logical units that do not check reserved fields.
>If designed with SPC-3 knowledge, it is supposed to return INVALID FIELD
>IN PARAMETER LIST.  The APTPL bit has always been defined, so it's safe
>to require it be checked in all versions of SPC-n.
>
>
>  
>
>>Thanks,
>>Kenneth Ray Craig, Jr.
>>    
>>
>
>--
>Rob Elliott, elliott at hp.com
>Hewlett-Packard Industry Standard Server Storage Advanced Technology
>https://ecardfile.com/id/RobElliott
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to majordomo at t10.org
>  
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list