Disks write-back cache
jmcgrath at qntm.com
Thu Mar 30 11:20:44 PST 1995
Reply to: RE>>Disks write-back cache b
On Mar 30, 9:44am, "Jim McGrath" wrote:
> We do not report deferred errors in general. We found that customer drivers
> did not expect or want this. Instead, we use the most extensive error
> process possible in the drive and back it up with automatic reallocation of
> error to a new portion of the media. The only drive failure mode that can
> defeat us is the inability to write anywhere for seconds at a time - true in
> a fatal drive failure (i.e. head crash), but very hard to induce otherwise
> (e.g. shock and vibration could do it, but it is very hard to defeat the
> for all those retries without also violating the drive shock and vibration
> specification - we have never seen such a case in practice).
> Given this, there is no real use in reporting a deffered error, since there
> no error recovery operation the system could perform on that drive that
> we have mot already attempted several times.
Larry, you wrote:
> On some systems that implement RAID or MIRROR disks, deferred error
> reporting could be helpful in recovering from this type of fault.
I agree, but once again the probability of that happening is much less than
standard 10^14 bit error rate for non-recoverable errors you see (largely
induced by bad writes) anyway. A correct RAID system interested in this
should either have enough redundancy to be fault tolerant of these failures
(since they occcur without write caching anyway), verify every write (which
eliminates the need for caching, since your performance is trashed anyway),
or implement background verify scanning of the disk to detect a bad write
when you still have redundancy from other drives to fix it. Note that if
you ask for cached write data we first make sure it has been written to the
before performing the read, precisely so that you can do this (although for
results use the VERIFY, not the read command).
More information about the T10