Jim Buzbee schrieb:
> We've got a bit of an issue. From conversations on this list over the
> last few months, it appears as if enabling the write cache on an IDE
> drive is a "bad thing" when using a journaling file system such as XFS.
> But, when talking to drive manufacturers, we are told that if the write
> cache is disabled, the life of the drive is substantially reduced. This
> puts us in a bit of a hard place. We have little choice but to turn the
> write cache on.
It's obvious that lifetime is reduced with write caching off. Just
listen to the drive and compare between w/cache on / off. What helps
here is that Linux uses memory for caching effectively.
Some weeks ago I brought an issue to this list. I got zero filled files
after _clean_ reboots and I thought it was the write cache of the IDE
drives not flushing correctly. In fact I got bitten by the 'remount
readonly bug' and it had nothing to do with the write chache being
> In our application, (consumer set top box) we cannot always cleanly shut
> down the system. The consumer rightly expects to just unplug the box
> when he wants/needs to. I'm not terribly concerned about losing a bit
> of data in such a case. I'm worried about file system corruption that
> would turn the box into an expensive door stop. My own testing so far
> has not shown any catastrophic failures, but if we have a million boxes
> in the field, issues could start showing up.
> The drive manufactures have recommended inserting IDE cache flushes at
> critical sections of the code. I'm hesitant to muck with XFS internals,
> and adding flushes in our user-space code would not cover all cases.
Cache flushing does only work if the drive honours the flushing request
correctly. What I recommend is trying to use drives which:
- really flush cache when requested to do so.
- flush cache on power failure.
The latter is quite important because comsumers will just pull power to
turn it off. I don't know whether this feature is available with IDE
drives but I think it should be possible.
> This has to be a common problem. Does anyone have any strategies or
> words of wisdom?
> Jim Buzbee,
> Echostar Technologies