01-173r0 SRP bidirectional residuals

Peter Johansson PJohansson at ACM.org
Tue May 22 10:22:58 PDT 2001


Before continuing this conversation (below) may I point out that all of us 
are on the reflector(s) and don't need to be individually CC:'ed. Me? I 
would rather not get the duplicated messages.

At 11:35 AM 5/22/01, Elliott, Robert wrote:

>Since SPC-2 says "The contents of the INFORMATION field is device-type or 
>command specific," any command set defining a bidirectional command should 
>be able to describe how the field should be filled for that command.

Any command set *should* be able to do this if there were enough bytes in 
enough fields to go around. The INFORMATION field is adequate for one 
residual for the direction implicit in a command.

But this begs the question. Even though, strictly speaking, each command 
set may define the usage of the INFORMATION field, SPC-2 offers guidance 
for the most common cases. I think SPC-n should extend this guidance to 
bi-directional commands.

Because I am loathe to expand "core" sense data, I have my eye on the 
COMMAND-SPECIFIC INFORMATION field that follows. Could SPC-n combine these 
fields and provide a matrix of their typical uses? For example, for 
commands unconcerned with LBAs, two quadlets of residual (one for each data 
transfer direction) might be useful. For bi-directional commands that use 
LBAs, it may be that there is never a necessity to report both 
simultaneously (i.e., the CHECK CONDITION might pertain to only one mode of 
the command), in which case 6 - 8 bytes of LBA information might be useful. 
I think some more discussion is in order.

>SPC-2 mentions that the INFORMATION field (which is four bytes long) 
>contains a LBA for direct-access devices.  Then it requires that the 
>logical block address must fit in two bytes or the INFORMATION field is 
>invalid. So, this seems pretty useless as currently defined.  According to 
>00-267r7, the two-byte rule was added in SPC-2 revision 19 per comment 
>6.10.  The resolution was concerned with > 2 TB LBAs, and should probably 
>say "four bytes" not "two bytes."  Ralph, can you slip this in with the 
>public review comments?

The public review period closed yesterday. However, I made an unrelated 
public comment. If T10 addresses that comment, it seems to me that this 
"thinko" could be rectified at the same time.

>Something will have to be done to create a larger INFORMATION field in 
>SPC-3 to support > 2 TB LBAs.  The solution should provide room so 
>bidirectional commands can specify two LBAs.

While I don't disagree, this is may cause operating systems a lot of 
indigestion if not carefully approached. I'm in favor of trying to do as 
much as we can within the core sense data and only venture out into 
additional sense bytes when absolutely necessary.


Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

PJohansson at ACM.org


******************************************************
SBP-3 protocol for FireWire Mailing List
Unsubscribing:
send email to requests at isg.apple.com with subject "unsubscribe sbp3"

Set to Digest Mode:
send email to requests at isg.apple.com with subject "subscribe digest sbp3"

Help?:
send email to requests at isg.apple.com with subject "help"
******************************************************




More information about the T10 mailing list