[t13] 04-136r0.pdf SCSI to ATA Command Translations
p.lavarre at ieee.org
Mon Jun 7 10:08:34 PDT 2004
This message is from the T13 list server.
// 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)
>>>>> () BLOCK LENGTH IN BYTES
>>>>> 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
>>>> MMC fixed the bytes/LBA at 2 Ki, shutting out the (empty set of?)=20
>>>> ATA MO
>>>> 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 like the (6) and (10) are pointless because (16) supercedes?
Pointless because (12) differs from (10) mostly by allowing more
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.
More information about the T10