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 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� 3Fh� N/A����� Not Supported > > > Read Long (10)� 3Eh� N/A����� Not Supported > > ... > > Why not?� 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 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 than the ECC read.
No?
It shut out nobody.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.
IMO the OS request block size _should_ be constant at 512 octets. 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 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 counting 2 KiB LBA's for PDT x05 DVD/ CD would simplify life. Indeed 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 LBA's inside of PDT x00.
Yes?
So any SCSI client that chokes over something other than 0.5 KiB LBA's for PDT x00 shuts out the MO folk. An example is a boot BIOS that begins life by asking to fetch x200 bytes from LBA x3F, when bytes/LBA is x400 or x800 or x1000, rather than x200.
Yes?
> 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.
Should be that way, aye. Often actually isn't, though rumour, be it truth or slander, say some MO now work this way because Microsoft 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 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 LBA/CDB, which merely reduces status/ command overhead, which almost 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>� 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� 1Eh� N/A����� Not Supported > > > > Why not?� ATA has an RMB bit too? > > I think I agree with your objection, > but I need to ponder more.
Hi.
Pat LaVarre
