read of zero is how vague really?

Mcgrath, Jim Jim_Mcgrath at maxtor.com
Wed Feb 27 15:41:19 PST 2002


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

Pat,

Flexstar is a popular manufacturer of test equipment used by a lot of our
customers.  If you look at www.flexstar.com under applications you can see
that they offer test scripts that test for compliance that run on their
hardware.  I'm sure there are other examples.

On the device you had problems with in 2001, was the internal translation in
something like a bridge or the actual device itself?  I've never seen this
problem in the devices (for HDDs), although it is certainly possible that
there are bad bridge vendors out there.  Remember that HDDs are extremely
high volumes qualified by a lot of customers - bridge vendors may not have
to serve a similarly demanding market.

On read errors, you can often induce then with excessive shock or vibration
of the drive.  It does not take much - the problem is in the timing.  So you
usually have to shake it during a lot of commands and only periodically get
an error.

Jim


-----Original Message-----
From: Pat LaVarre [mailto:LAVARRE at iomega.com]
Sent: Wednesday, February 27, 2002 7:57 AM
To: t10 at t10.org
Subject: RE: read of zero is how vague really?


* 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_de
vs.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
*
* 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