This message is from the T13 list server.
As I asked in the previous email, I don't see a proposal for the WRITE DMA QUEUED FUA command. But looking at the ATA/ATAPI-7 description (both the general description of O/Q and the command description) I don't see a problem. Basically this command is a O/Q command (so it does not abort the outstanding command queue) but it is a command that is not allowed to release (so it executes like an non-O/Q command). Yes, that may be a big performance problem but that is the price you pay. HOWEVER, there is a big problem if the host is dumb and has outstanding O/Q commands, read and/or write, that access the same sectors that another O/Q command accesses (including the WRITE DMA QUEUED FUA command). Again, unless I missed something, I think ATA/ATAPI-x has nothing to say about the action and/or data integrity of O/Q commands that access the same sectors. I think when O/Q was added for hard disk drives T13 assumed this was the host's problem. But the O/Q EXT commands have yet another problem (that I have asked about before). If these commands are used with really large transfer lengths (remember that and EXT command can tranfer up to 65536 secotors or about 33Mbytes of data) these commands have a real performance problem in that only one release/service cycle is allowed (and that must be before any data is tranferred). The ATAPI DMA O/Q option of the PACKET command allows a device to release/service multiple times (before and during the data transfer). O/Q EXT commands should allow the same for hard disk drives. Now the "real" question... Does any of this O/Q stuff matter? Doesn't SATA have something that replaces all this old PATA O/Q stuff? Hale *** Hale Landis *** www.ata-atapi.com ***
