This message is from the T13 list server.
Hale,
I don't understand your interest of a disk drive cache
algorithm. The only behavior the host can assume about a disk cache is
that it doesn't change the behavior of the drive. Once the drive has
signaled the completion of a transfer, it doesn't matter to the host
where the data physically lives as long as the next time it does a read,
it gets the same data back.
Because the FUA commands do not affect the internal queuing or
write ordering of the disk, FUA commands are no more of a data integrity
problem for the host then normal write and queued write commands. In
fact, FUA commands don't even affect the caching on the disk. FUA data
transfers can still be cached, they just can't be signaled complete
until the command is written to disk.
Nathan
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hale
Landis
Sent: Thursday, June 26, 2003 9:50 PM
To: [EMAIL PROTECTED]
Subject: Re: [t13] Re: hmmm.. no comments?
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 ***
