de facto obsolete sbc-2 ops - 8Bh

Pat LaVarre LAVARRE at iomega.com
Thu Feb 21 11:03:41 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
>>> "Mcgrath, Jim" <Jim_Mcgrath at maxtor.com> 02/20/02 07:50PM >>>

> although I think a lot of people
> will never change their code at all
> (a lot of it is in manufacturing and test).

Eh?  Lost me here.

We're not saying we think people empowered to demand vendor-specific changes who now use x2B Seek will suddenly see the light and stop demanding support for seeks, just because that op is no longer standard, are we?

> I think a lot of people just didn't like
> the functionality of SEEK
> since it harkins back to the days
> of HDDs and controllers being separate
> i.e. you use to have to SEEK to some cylinder,

How much of an x2F Verify for 1 block is an x2B seek?

I've never understood exactly what a Seek to an Lba was supposed to mean for a random track device like an HDD ... is a seek and a head-switch to the track containing the Lba good enough, or are you supposed to incur a rotational latency til you reach the Lab?  Do you have to settle stable on track, or is it ok if the track is findable but not trackable?  Etc.

> and then use another mechanism to read/write.
> With integrated controllers,
> you just do a READ or WRITE command.

Aye.

> With READ(10) a transfer length of 0
> indicates no data transferred -
> READ(16) will be the same.

Ah.  Interesting as always, thank you again.

I had learned to avoid read/write of 0 blocks because enough people don't think too hard about that limiting case.

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.

> > Ata

Last I checked, Ata couldn't express a read of 0, but it could seek.

I see the rev 3a 14 Dec 2001 Ata/pi 6 defines no SEEK EXT.  That is, T13 left the Ata op x70 SEEK out of the 48 bit extension and thus quietly limited seeks to 28 bit Lba's (128GiB @ 0.5KiB/block).

All the same, in a key difference from T10 Scsi, T13 Ata effectively grew all their Cdb's with its 48-bit Lba extension.

By letting the host write ports x1F1..1F5 twice, T13 in effect grew the size of any Cdb moved out from what had been a fixed eight bytes to now a fixed thirteen bytes, with each opcode continuing to say which of the now thirteen bytes are meaningful, even vendor-specific opcodes, even obsolete opcodes like Ata ops x23/33 Read/WriteLong.

> READ ... transfer length of 0 ...
> ... will serve for people
> who really need a SEEK(16),

Now that you point this out, I buy that guess ... if we can say the prefill-the-cache function often associated with a read of 0 blocks will die out.

Else I imagine people will get by with x8F Verify(16).

Pat LaVarre

-----Original Message-----
From: Pat LaVarre [mailto:LAVARRE at iomega.com] 
Sent: Wednesday, February 20, 2002 8:25 AM
To: t10 at t10.org 
Subject: de facto obsolete sbc-2 ops - 8Bh


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> > Can we obsolete x8B?
> > On the theory that for some people 
> > this will be the Seek op for 64-bit Lba's?

> "Elliott, Robert" <Robert.Elliott at COMPAQ.com> 02/19/02 12:51PM
> ... opcodes are a rare commodity;
> we don't want to discard them
> just because the lower bits match
> some other opcode's lower bits
> (SEEK(6) at 0Bh and SEEK(10) at 2Bh).

Somebody please elaborate?

I missed the whole why not carry Seek forward beyond 2TiB @ 0.5KiB/block
discussion, back whenever it occurred?

I came to expect to see Seek(16) at x8B as follows:

1) I think I saw we Sbc folk have Read in 6, 10, 12, and 16 bytes forms at x
08 28 A8 88.  I saw we have Write at x 0A 2A AA 8A.  I saw we have
WriteVerify at x 2E AE 8E.  I saw we have Verify at x 2F AF 8F.  In contrast
to all this, I saw as yet we have Seek only at x 0B 2B.

2) I think I saw the significant distinction between the required x 28 2A
and the optional x A8 AA goes commonly unused in a commodity PC.  With x A8
AA we raise the max block count above xFF:FF, aye.  But we don't raise the
max expressible Lba and we don't alter the deeply regrettable fact that
Wintel favours block counts of x00:80 and below.

3) The main point I saw in progressions like x 08 28 88 was to raise the
maxLba expressible from x1F:FF:FF (1GiB @ 0.5KiB/block) to xFF:FF:FF:FF
(2TiB) to xff:ff:ff:ff:FF:FF:FF:FF.

Thus I came to expect to see Seek(16) at x8B, for devices that store more
than 2TiB @ 0.5KiB/block,

If people aren't putting Seek(16) there, where are they putting it?  Out
among the ops whose Cdb length's are less determinate?  That's hard to
credit: those ops are hard to transport across platforms.


> 16-bit opcodes are a rare commodity;

Somebody help me out with terminology here?  I got lost in the "16-bit
opcodes" part.

Unless corrected I'll take this English to mean to say that the ops x00..FF
are a precious resource.  Most precious are the ops that are not
vendor-specific yet but still have long established Cdb lengths i.e. x00..5F
A0..BF.  Next most precious are the not vendor-specific ops of newly
specified Cdb length i.e. x7F..9F.

I thought the original Scsi had "8-bit" ops but x7F is an escape op that
gives us a fresh new "16-bit" op space aka the "service action" sub-op.


> opcodes are a rare commodity;

I count myself as a language lawyer.  I find specs, I buy a copy of the
official draft (I even have an official Scsi 1), I read the specs, I try to
understand the specs ... all sometime before/as I code an implementation.

I haven't really "read" the Sbc docs - but on my first glance, it seemed to
me that x8B was quietly left out.

I'm given to understand a lot of people in our business are less careful -
which makes me think x8B is going to be Seek(16) whether we like it here or
not.  If that's true, then we'd do better to admit that up front than to try
and patch up life later.


> opcodes are a rare commodity;

Maybe we should make x8B Vendor-Specific rather than Obsolete, so device
folk get at least one 16 byte Cdb they can use for whatever purpose?  I
think I see the July 2001 rev 4 Sbc-2 makes vendor-specific only Cdb's of 6,
10, and indeterminate byte length?


Pat LaVarre


> I count myself as a language lawyer

Courtesy <http://www.tuxedo.org/~esr/jargon/html/entry/language-lawyer.html>
we know: ... 'A language lawyer is distinguished by the ability to show you
the five sentences scattered through a 200-plus-page manual that together
imply the answer to your question "if only you had thought to look there"
...'

But the t10 texts I don't (yet?) know well.


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