read of zero is how vague really?

Pat LaVarre LAVARRE at iomega.com
Wed Feb 27 07:56:52 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> > Neither do I have Any Good Way
> > of measuring precisely how indeterminate is
> > the effect of x00 as the cdb[4] transferLength.
...
> > What's left in question then
> > is how unreal this paper claim is, among others.
...
> > What I'm sure about is that what is rare
> > works less well than what is common.

Sorry I was not more clear.  Here I am trying to share my personal history of felt pain.  I do mean to be talking practice, not theory: real devices, not paperware, actual flagrant disregard of the work of the T10 committee.  I am interested in getting a feel for how unique my experience of disregard in the aftermarket is or is not.  Three points:


1) Here now I'm talking about summer 2001, not the ancient past.

Specifically then I saw a shipping hard drive move 0 bytes in response to the cdb x 08 00:00:00 00 00 i.e. Read6 for x1:00 blocks.  This was an aftermarket drive, not OEM'ed.  It may have had a Microsoft WHQL logo, I don't remember.  The root cause was an inaccurate internal translation between op x08 Read6 and op x28 Read10.

Equally creative Scsi interpretations observed in specific devices from named vendors appear published in such places as <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linux-usb/storage/unusual_devs.h?only_with_tag=HEAD>.  There the word "hard" gets about five hits and counting.


2) Did we just now mean to say there really are useful & commercially available t10-compliance test suites made by people still in business?

Can anyone here post links to more specific references?  Links to happy commendations from a customer who already spent the money?

Do we know specifically of still selling test suites useful enough to automagically notice if x 08 00:00:00 00 00 moved 0 bytes rather than than x100 blocks?

Me, before, I knew of just two such test suites, and the vendors for both of those had since gone out of business.  Me, I was thinking that the consistent failure of such people to make money made such a test suite a fundamentally non-commercial exercise - a necessarily open source project.

For example, with source drawn from the web, I can see here that a Win98 connection to a Quantum Fireball SE4 moves in max(cdb[4], 0x24) bytes in response to the cdb x 12 0 0 0 24 0 i.e. Inquiry for up to x24 bytes.  And the first eight bytes - including the additionalLength at offset 4 - are always zeroed.

I know to blame Microsoft rather than Quantum for this intensively creative SPC interpretation - max where SPC says min, zero where SPC says additionalLength - only because I believe the Quantum device here is purely an Ata device, without Atapi support, so the interpretation of the cdb has to be Microsoft's, not Quantum's.


3)

Agreed, people do the Right Thing more often when we make it easy.  Agreed, all else being equal, static conditions are easier to test than dynamic.  Agreed, commodity storage devices by design make errors difficult to observe - in particular, there has never been a standard for injecting write errors.  Agreed design to make dynamic behaviour match static behaviour is Goodness.

> all else being equal, static ... easier ... dynamic

I trust we agree all else being equal often isn't.  Examples of static tests commonly difficult to perform include:

3a) Slow reads and unrecovered read errors.  Now harder to inject where we want them, since for 64 bit Lba's we have decided to provide no standard analogue to the ops x3E/3F Read/WriteLong.

3b) Having the first N commands be other than standard.

3c) Delaying or suppressing or corrupting auto sense.

...

Pat LaVarre

>>> Mcgrath, Jim 02/25/02 02:46PM >>>
* 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




More information about the T10 mailing list