This message is from the T13 list server.
Pat LaVarre wrote:
3.1.2 SCSI INQUIRY CDB format and supported fields
I mis/remember MMC requires a zero in the byte 2 Version field of op x12 "INQUIRY" data ... compatibility there could force us to pay attention to how to report version in the standard bytes that follow the vendor-specific bytes out past offset x24.
Most ATAPI and USB devices report zero in the version field.
My choice in Linux is to simulate MMC-3 version, and supply auto-sensing capability even when the low-level device does not.
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, like MMC fixed the bytes/LBA at 2 Ki, shutting out the (empty set of?) ATA MO folk.
I like that.
It shut out nobody.
IMO the OS request block size _should_ be constant at 512 octets. 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.
However, any device with a non-power-of-two sector size should be shot on sight ;-) SATA specification mentions such devices... grumble.
For the Read(12) command, if the size TRANSFER LENGTH field is greater than 16 bits, then the command will terminate with a check condition where the sense key set to illegal request and additional sense code set to invalid field in CDB.
I like that. I independently reached that conclusion and shipped that solution once, together with a comment something like "Comdex, 1996, nothing so permanent as a temporary kluge". So far as I know, noone ever returned to that code to kick up the max LBA's/CDB past xFFFF.
<shrug> It's required by the underlying ATA device, not much else you can do but limit to 0xffff -- or even 0xff for non-lba48 devices.
For lba28 devices, Linux limits you to 0xff (actually a tiny bit less) as expected.
Jeff
