residue of 1394 Sbp-2 - forget it?

Mcgrath, Jim Jim_Mcgrath at maxtor.com
Wed Mar 6 15:18:13 PST 2002


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

Pat,

The problem here is that you are applying the T10 standards at the wrong
level of interface:

"I also see the Microsoft device on my desk that interprets an op x12
Inquiry cdb to mean move in MAX(cdb[4], 0x24 - 8) bytes in, after moving in
eight zeroed bytes.  Those eight zeroed bytes include the byte at offset 4,
that T10 tries to say is the additional Length."

What Microsoft (or Apple, or Linux, etc...) does at the software API
interfaces have no necessary relationship to anything in any T10 document.
Those standards standardize exactly what they standardize, and nothing more.
Traditionally this just means what goes across the parallel SCSI bus.  In
recent years other transport mechanisms (1394, ATA, Ethernet) have been used
to move around SCSI commands, data, and status.  Their common denominators
are all specified in the SAM (SCSI Architecture Model) standard.  None of
this has anything to do with what Microsoft drivers do, since that is not
the level at which they operate.

I'm sure that is you snoop the parallel SCSI, 1394, etc... physical bus
you'll see the bytes you expect, including in the case you cited the
additional length indicator.  If an upper level driver wants to hide that
|from other layers of software, then it certainly can - that has nothing to
do with T10, or even SCSI per se.

In the past there have been attempts to standardize higher layers of
software (e.g. CAM), but they met with limited market success.  Software
folks appear to be less inclined to agree to a common standard than the
hardware vendors.

Jim


-----Original Message-----
From: Pat LaVarre [mailto:LAVARRE at iomega.com]
Sent: Wednesday, March 06, 2002 2:31 PM
To: sbp3 at isg.apple.com
Cc: t10 at t10.org
Subject: Re: residue of 1394 Sbp-2 - forget it?


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> David Wooten 03/05/02 03:11PM
> residual/residue count is ... command set

Good fun, thank you, we hold eye-poppingly different assumptions here.

Til I met 1394 Sbp-2, I had never met a storage protocol designed to be
completely unable to count bytes moved.

The device model I knew was close kin to the standard i/o of C where I saw
it first in 197X: you tell me how many bytes I may move, and I'll tell you
how many bytes I did move, or else I'll reject your request altogether.

This is the device model I see in generic UsbMass, in Dos/Win Aspi, in Win
Ioctl, etc. etc. etc.

I think we're now telling me 1394 Sbp-2 differs here from iScsi, UsbMass,
etc. etc. etc.   We're saying 1394 Sbp-2 by design flatly abandons this
traditional responsibility to count residues accurately, giving this duty
over to the (not likely) invention of new & improved command sets.

> Peter Johansson 03/05/02 03:54PM
> As long as the bridge ... moves the data
> and faithfully reports
> whatever the endpoint device
> has to say about residue

We agree then that Sbp-2 neglects to specify HOW to do this?

Let's suppose the raw device is Scsi, printer port Scsi, AtapiPio, or
UsbMass.

In any of those protocols, the device gets Two chances to comment on
residue.  Sure, the device can fail a cdb and provide auto-sense data.  But
also the device can merely cut the data transfer short.  In Scsi, the device
deasserts REQ.  In Atapi, the device deasserts DRQ.  In UsbMass, the device
reports nonzero dCSWDataResidue.

Now tell me how, as a bridge from 1394 to any of these others, how can I
faithfully pass back the fact that the device did cut the data short?

I see I could ignore the residue altogether.  I see I could alter the
passing status and fabricate auto-sense data.

I see no standard that tells me when to do either, nor what SK ASC ASCQ to
fabricate.

> Peter Johansson 03/05/02 03:53PM
> Commands typically fall into ... classes

Yes, though no standard identifies these classes.

> ... commands, such as disk READ or WRITE,
> for which GOOD status means
> that all the bytes were transferred.

All which bytes.

I see a bridge from 1394 can know if all of the data buffer did transfer.  I
don't see that a bridge from 1394 can know if transferring less than all the
bytes of the data buffer is in fact an error.

I don't (yet) have much data here ... anybody have an opinion over whether I
wrong to bet that most external 1394 hard drives built out of 1394 bridges
to Ata do Not consider nonzero residue to be an error?

> ... commands, such as INQUIRY,
> that may not make use of all the buffer space
> provided by the initiator
> even when they complete with GOOD status.
> In my experience, the data returned
> by these commands is self-descriptive;

Hmmm.

You mean to say "experience"?  Not just publications?  Actual behaviour of
actual devices available in mass?

I agree the texts at <http://www.t10.org/scsi-3.htm> have clearly claimed
for ages past, for example, that byte 4 of op x12 Inquiry data should
contain the additionalLength.

I also see the Microsoft device on my desk that interprets an op x12 Inquiry
cdb to mean move in MAX(cdb[4], 0x24 - 8) bytes in, after moving in eight
zeroed bytes.  Those eight zeroed bytes include the byte at offset 4, that
T10 tries to say is the additionalLength.

I like having a low layer of the i/o system tell me how many bytes moved.
That's the foundation on which I'm used to building layers that then make
sense of the bytes.  Myself having to count the bytes that move in, having
noone bother to count the bytes that move out, those ideas are new to me.

Thanks again.    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