[t13] 04-136r0.pdf SCSI to ATA Command Translations

Pat LaVarre p.lavarre at IEEE.org
Mon Jun 7 10:08:34 PDT 2004

* From the T10 Reflector (t10 at t10.org), posted by:
* Pat LaVarre <p.lavarre at ieee.org>
// Jeff G:

 > My choice in Linux is to simulate MMC-3
 > version, ...

Eh?  Linux implements a PDT x00 variation on the MMC-3 that t10.org=20
defines only for PDT x05?

 > For lba28 devices,
 > Linux limits you to 0xff (actually a tiny bit
 > less) as expected.

Linux lba28 max is xFE LBA's per CDB?

 > > > Write Long=A0 3Fh=A0 N/A=A0=A0=A0=A0=A0 Not Supported
 > > > Read Long (10)=A0 3Eh=A0 N/A=A0=A0=A0=A0=A0 Not Supported
 > > ...
 > > Why not?=A0 How do we inject read errors?
 > ...
 > Simple answer:
 > there is no meaningful translation to ATA.
 > ...
 > Without using vendor-specific commands, anyway.

Eh??  Read/ write long doesn't work in ATA?

I thought I was just ignorant, that true ATA gurus knew how to=20
negotiate more than 4 bytes of ECC per 512 bytes of data, and therefore =

commonly succeed in injecting read errors by writing back ECC other=20
than the ECC read.


>>>>> 3.2 Read Capacity (10) Command  (25h)
>>>>> This value is currently set to 512 bytes,
>>>>> which is the standard sector size for disk drives.
>>>> I see us taking the chance to try to fix the bytes/LBA at 0.5 Ki,=20
>>>> like
>>>> MMC fixed the bytes/LBA at 2 Ki, shutting out the (empty set of?)=20
>>>> ATA MO
>>>> folk.
>>>> I like that.
>>> It shut out nobody.
>>> IMO the OS request block size _should_ be constant at 512 octets. =20
>>> It makes calculations easier, and representations more normal.
>> Please do not forget CD/DVD writers.
>> They use 2048 Bytes per block.
> That's fine, it's a multiple of 512.

Sounds like violent agreement to me.

Yes always counting bytes would simplify life.  Failing that, then yes=20
always counting 0.5 KiB blocks would simplify life.  Failing that, then =

yes always counting 0.5 KiB LBA's for PDT x00 HDD/ Flash and always=20
counting 2 KiB LBA's for PDT x05 DVD/ CD would simplify life.  Indeed=20
the PDT x05 texts require the device to report 2 KiB/LBA.

Meanwhile, the MO folk actually do report something other than 0.5 KiB=20
LBA's inside of PDT x00.


So any SCSI client that chokes over something other than 0.5 KiB LBA's=20
for PDT x00 shuts out the MO folk.  An example is a boot BIOS that=20
begins life by asking to fetch x200 bytes from LBA x3F, when bytes/LBA=20
is x400 or x800 or x1000, rather than x200.


 > IMO the OS request block size _should_ be
 > constant at 512 octets.=A0 It makes calculations
 > easier, and representations more normal.
 > For MO devices with >512 sector sizes are
 > fine, just make sure the OS always sends down
 > a multiple of 512-byte sectors as required by
 > the device.

Should be that way, aye.  Often actually isn't, though rumour, be it=20
truth or slander, say some MO now work this way because Microsoft=20
shipped a version of Windows (maybe Win ME) that choked otherwise.

 > Most ATAPI ... devices report zero in the
 > version field.

I agree - I have myself never seen anything else there.

 > Most .... USB devices report zero in the
 > version field.

Aye, having been built by combining a PATAPI device with a reasonably=20
transparent USB/ PATAPI bridge.

 > any device with a non-power-of-two sector size
 > should be shot on sight ;-)

Such as CD long blocks of x930 (2352) bytes of data plus ECC.

 > > op x88 Read(16) and op x8A Write(16)?
 > Linux implements ...
 > I disagree with the T10 proposal
 > that it should not be implemented.

Maybe 64 bit max LBA is happening now in RAID for capacity.

 > The (12) variants are pointless.
 > I did not bother to implement them,
 > since READ/WRITE(16) translation is fully
 > supported by Linux.

Pointless why?

Pointless like the (6) and (10) are pointless because (16) supercedes?

Pointless because (12) differs from (10) mostly by allowing more=20
LBA/CDB, which merely reduces status/ command overhead, which almost=20
always is already small enough not to matter?

 > > > ... if the size TRANSFER LENGTH field is
 > > > greater than 16 bits, then illegal request
 > > > and ... invalid field in CDB.
 > > ...
 > > once, ... a comment something like "Comdex,
 > > 1996, nothing so permanent as a temporary
 > > kluge" ... max LBA's/CDB ... xFFFF.
 > <shrug>=A0 It's required by the underlying ATA
 > device, not much else you can do

Nothing except arrange for lba48 to replace lba28, aye.

 > > > Prevent Allow Medium Removal=A0 1Eh=A0 N/A=A0=A0=A0=A0=A0 Not =
 > >
 > > Why not?=A0 ATA has an RMB bit too?
 > I think I agree with your objection,
 > but I need to ponder more.


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