This message is from the T13 list server.
Since I started the "hmmm.. no comments" message thread and now there seems to be some confusion about the FUA commands, let me try an explaination... First, it seems that Microsoft proposed four new commands, WRITE DMA FUA, WRITE DMA EXT FUA, WRITE MULTIPLE FUA and WRITE MULTIPLE EXT FUA. These are not Overlap/Queued (O/Q) commands. But only the WRITE DMA EXT FUA and WRITE MULTIPLE EXT FUA were added to ATA/ATAPI-7. I guess that was OK with Microsoft? And if these commands operate the way Nathan Obr says they should (see his email this evening) then yes, data integrity of write cached data in the drive is the host's problem. Second, T13 must have decided to also add WRITE DMA QUEUED EXT FUA. There does not seem to be a proposal for this command. This is the command additional data integrity problems. However, again, if implemented per Nathan Obr's message tonight then yes, data integrity of write cached data in the drive is the host's problem. Clearly the description(s) of these commands need to be updated. And the statement describing these commands in the general description of the O/Q feature set needs to be deleted or re-written. In my opinion there is only one way to address the data integrity problem (without making the whole thing so complex it will never work right): Say that data integrity is the host's problem - don't use a QUEUED FUA write command to write data that is also being written by a normal QUEUED (not FUA) write command that has not completed. ATA/ATAPI-x doesn't currently say anything about how a drive must handle write cached data (except in the FLUSH CACHE commands). I see no reason to change that attitude because of the FUA commands, unless T13 wants to *FULLY* describe the complete algorithm for write (and read) cache operation (that would only add another 20-50 pages to the document!). Note that drive implementations understand the problem of multiple writes to the same sector address that are cached and a read to one of those sector addresses will return the correct (newest) data. If this was not true then I know of some test software that would report lots of data compare errors. QUEUED write commands just add a little extra problem for the host because the write data may not be in the drive's cache yet when the QUEUED read command for the same sector address is received. OK, now anyone want to propose a *FULL* description of the "standard" disk drive cache algorighm? Hale *** Hale Landis *** www.ata-atapi.com ***
