Imbedded response below:
On Tuesday, June 24, 2003, at 11:02 AM, Pat LaVarre wrote:
This message is from the T13 list server.I also have seen (SCSI) drives which lied about seek "immediate". Those were easy to spot because the following read took too long. I'm not sure how you 'lie' about write "behind", because the whole concept is a lie. That's why it's so vital that the Flush cache actually works.
With my own eyes I have only seen drives faking good status for seek "immediate" and write "behind", never for flush. But I'm curious now:
First of all, we ask them. If they give the wrong answer we make sure they correct it. I'm not sure that every drive model is explicitly tested for write cache command integrity. It can be tested by filling the write cache (usually with single blocks in reverse order) and then killing the power immediately after the Flush Cache.
How do people prove that a drive whose firmware we did not write has not lied about flushing?
People do ( sometimes accidentally ;-)
Do people actually write and flush and cycle power and read back?
Drives are designed to withstand a certain number of emergency retracts ( usually in the 10's of thousands). This type of testing reduces the life of the drive, but it is valid for qualification.
Do people design hard drives to withstand much such usage?
Regards,
Pat LaVarre
...Harlan
What can I say? I'm sure Microsoft would not do such a thing on purpose, but this FUA request makes me wonder.
P.S. My own checking balance was uncomfortably wrong once because in balancing my books I typed an excessively creative data flow into Excel: a flow that was not upper left to lower right. Turns out the Office 97 version was well known to give wrong answers to some such data flows, to the point of eating even explicit refresh requests. Microsoft suggested some obscure three-finger salute designed to mean please take my refresh request more seriously.
Good file systems should attempt to maintain coherency in spite of random power failures. One way to do that is to create a copy of the changed directory structure which is then flushed to the media BEFORE linking it in to the real directory. That way if the power failure occurs before the link write the previous directory is valid. If the power failure occurs after the link write the changed directory valid. FUA could invalidate such operation if the link block gets written ahead of the copied structure and the power fails with the copied structure still in the drives buffer.
Modern OS's typically maintains a write cache in main memory. This mitigates the performance loss due to flush cache. That is one reason why flush cache is so important. Prior to flush cache people used various other means (such as standby immediate) to force data to the media.
Unfortunately, the bench mark programs tend to make the drives keep data in their buffer longer then necessary. This often results in poor multimedia results since the drive waits until buffer is completely full and then dumps the whole thing before doing the next operation. This can result in a noticeable glitch in sound or video when the drives buffer actually does the flush. We try to reduce these "Slow Reads" or "Slow Writes" by detecting them and requesting that they be fixed. Usually the fix is to flush the data to the media more often (before the write buffer is actually filled). This can have a small hit on the benchmarks, but actual system performance is improved AND the vulnerability to random power failures is reduced.
-----Original Message----- From: Harlan Andrews [mailto:[EMAIL PROTECTED] Sent: Tue 6/24/2003 11:21 AM To: T13 List Server Cc: Subject: Re: [t13] hmmm.. no comments?
...
I have also seen comments in this thread which imply that some drives do not actually flush the data to the media during the flush cache command. I have never seen this. Any drive which lies about flush cache would be disqualified.
...Harlan
