residue of 1394 Sbp-2 - forget it?

Pat LaVarre LAVARRE at iomega.com
Wed Mar 6 16:04:00 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> SBP-2 ...n't a storage protocol.

Thank you again: again a mind-expanding difference in perspective.

> If keeping track of the number of bytes moved
> is a result of an encapsulated command ....

I gather the phrase "1394 Sbp-2" isn't adequately specific, sorry.

Is there a preferred short alternative phrase I should use to mean "the
storage protocol used to let PC's read back what they wrote to 1394 mass
storage devices"?

> someone needs to sit down and map those command sets
> onto the different transport layer
> to figure out how things like residual are going to be reported.
> I think that this is not an uncommon thing in the industry.

Yes.

Not that anyone has yet bothered to publish their opinon of how to do this,
best as I can tell.  I wonder how violently people actually do differ over
this unwritten standard.  I hear Cd-rw's are unworkable unless you keep a
table of mutually contradictory behaviours.

> SBC and ATA

T10 Scsi Sbc & T13 Ata are different enough that the bridge has to translate
the command sets, starting with the opcodes and moving on from there.  Wanna
bridge something new?  Sorry, you gotta go get a new bridge..

I can see implementing an Scsi Sbc 1394 device that uses an Ata drive as
backing store.  What I don't get is how to pass cdb's and data and status thru
_transparently_ to parallel Scsi, Scsi Atapi, Scsi UsbMass, etc.

Seems to me, with Sbp-2, the bridge is stuck translating the command set.  The
bridge has to form a redundant opinion of how many bytes should move which
way, just so that it can check that is indeed what happens, just so that it
can report inappropriately nonzero residue as an error.

Yeeeuck.  Translating the command set gives the bridge folk a plug 'n pray
burden to carry comparable to the mess that Apple, Microsoft, Linux, & friends
carry.  Yeeeuck.

An alternative is to flatly ignore inappropriately nonzero residue - just hope
it doesn't happen any more often than your o.s. crashes anyway.

Another alternative is to use a vendor-specific driver to guarantee that the
length of the data buffer is always precisely the count of bytes that should
move, rather than the max that may move.

Anybody know of other, less distasteful alternatives?

Pat LaVarre

>>> David Wooten 03/06/02 03:53PM >>>
Pat,

A few responses below.

David Wooten

> -----Original Message-----
> From: sbp3 at isg.apple.com [mailto:sbp3 at isg.apple.com]On Behalf Of Pat
> LaVarre
> 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?
>
>
> > 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.
>

DRW: Well, I had the unfair/unfortunate advantage of having been at the SBP-2
meetings where we spent a long time arguing about what the heck SBP-2 is
supposed to be.  We concluded that it wasn't a storage protocol.  It is a
protocol to be used to encapsulate other protocols that didn't support memory
semantics.  1394 allows devices to move data directly to/from system memory. 
SCSI doesn't.  So, we put the (insert favorite device command protocol here)
commands inside a wrapper that adds the memory semantics and some other, 1394
related stuff.  Clearly, SPB-2 can be used as a storage protocol, but it can
also be used for other things.  If keeping track of the number of bytes moved
as a result of an encapsulated command then the status structure is more than
capable of providing a place to put that information.


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

DRW: Your historical perspective is interesting, but, given that SBP-2 isn't
intended to be a protocol for controlling mass storage, I don't think that it
was a cop-out to not include the residual counts.  There are applications for
which the notion of a residual count has no useful meaning.  Either the
command completes or it doesn't. Also, although someone decided to use the
development of SBP-2 as an excuse for creating RBC, I don't think that new
command sets need to be invented to make SBP useful.  What does, however need
to happen is that someone needs to sit down and map those command sets onto
the different transport layer to figure out how things like residual are going
to be reported.  I thing that this is not an uncommon thing in the industry. 
I may be wrong but I think that you will find that SBC and ATA have a lot in
common, status reporting not being one of those things in common.  The command
set is easy to move between different transport media, status isn't so easy
and needs to be addressed separately.
...

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