read of zero is how vague really?

Pat LaVarre LAVARRE at iomega.com
Mon Feb 25 08:09:18 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> > AFAIK T10 has always said x100  blocks.

> ... 02/24/02 10:12AM
> READ(6) of 0 means return 256 blocks.

Sorry I was unclear.

I mean to say, I think I remember the paper spec's from Ansi have all more or less clearly claimed that x00 as the cdb[4] transferLength means x1:00 (256).  (I just now checked again: I see even the June, 1986 Scsi 1 8.2.2 says this for the op x08 now known as Read6.)

What's left in question then is how unreal this paper claim is, among others.

> > ... I had learned to avoid read/write of 0 blocks because enough 
> > people don't think too hard about that limiting case.

I mean to say that I observe some device folk who implement x08/0A Read/Write(6) don't bother to include the substitution of x1:00 for x00.

I see this as one popular way of persuading a device and host to disagree over how many bytes should move which way.  In this example, some devices actually decide to move (0 * blockSize) bytes when the host expected (x100 * blockSize) bytes to move.

I don't really understand why devices behave this way.

For me, I think I remember, the separation of the x00 transfer length as a special case was one of the first weirdnesses that caught me eye in my first readings of the paper specs.

I see this spec design choice as akin to the <limits.h> SHRT_MAX of standard C - optimisation carried enthusiastically a little too far, sacrificing simplicity with abandon.  I mean, did any customer ever really care if x100 rather than xFF was the limit on blocks per Cdb?

Indeed, seeing x00 defined to mean x1:00 but x00:00 Not correspondingly defined to mean x1:00:00 (65536) suggested to me that I'm not alone in seeing the idea x00 = x1:00 as an almost never useful optimisation that gives the device extra work to do for every op x08/0A cdb received.

> I don't really understand why devices behave this way.

Neither do I have Any Good Way of measuring precisely how indeterminate is the effect of x00 as the cdb[4] transferLength.

Accordingly, in my day to day work, I try to duck this issue.

For example, working on the host, coping with the absence of a standard for x8B Seek(16), I I think I'd first try substituting a single block x8F Verify(16).

Mind you, I'm not clear on how rare single block Verify's are either.  What I'm sure about is that what is rare works less well than what is common.

> > > With READ(10) a transfer length of 0
> > > indicates no data transferred -
> > > READ(16) will be the same.
> > 
> > I know devices differ over whether a Read(6) of 0 means 0 
> > blocks or x100 blocks.  (AFAIK T10 has always said x100 
> > blocks.)  I've never seen a Read(10) of 0 mean anything but 
> > 0, but I haven't looked too hard.
...
> READ(6) of 0 means return 256 blocks.
> READ(10)(12)(16) of 0 mean return 0 blocks.
> 
> ... things ... added to SBC-2 ... notes in the
> READ(6) and READ(10) sections highlighting this disparity.

Thanks for the pointer.  From sbc2r04.pdf, I quote:

"5.1.6 READ (6) command
...
"Note 8 - For the READ (10) command, a TRANSFER LENGTH of zero indicates that no logical blocks are transferred.
...
"5.1.7 READ (10) command
...
"Note 10 - For the READ (6) command, a TRANSFER LENGTH of zero indicates that 256 logical blocks are transferred.

I share your hope that over time the existence of these notes will help real people less inaccurately  translate among x08 Read6, x28 Read10, xA8 Read12, and x88 Read16.

Pat LaVarre


*
* 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