read of zero is how vague really?

Mcgrath, Jim Jim_Mcgrath at maxtor.com
Mon Feb 25 13:46:04 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Mcgrath, Jim" <Jim_Mcgrath at maxtor.com>
*

Pat,

I've actually never seen a HDD that did not get the transfer length right (I
cannot speak of direct knowledge about optical storage).  Precisely because
it is a boundary case, it is and always has been routinely tested by our
customers.  Indeed, there are common software packages that test for all
sorts of things like this (e.g. RESERVED bits and the like).  In my
experience this has never been a particular problem.

Your concern about uncommon situations is correct, but has to be qualified
by the ease of testing.  Testing a parameter value is very simple,
especially at boundary conditions, so that is not usually a big problem.
The problem is when you are testing something rarely used in a much more
complicated and difficult to reproduce (and thus test) environment.  The
classic case here is error recovery, since by its very nature the triggering
event can be quite uncommon and result from a complicated set of hard to
reproduce circumstances.

My advice to people is not to worry about static conditions like parameter
passing, but worry alot about dynamic conditions that occur infrequently.
That's why I've always been a strong advocate of using the simplest error
recovery mechanism at the host level - its here that I've found the hardest
to resolve problems for customers over the years.

Jim


-----Original Message-----
From: Pat LaVarre [mailto:LAVARRE at iomega.com]
Sent: Monday, February 25, 2002 8:09 AM
To: t10 at t10.org
Subject: read of zero is how vague really?


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