| Using a write-back cache on a disk controller is an aggressive step: it
means that the controller tells the operating system that a write is
complete even though it has not been written to permanent storage.
The documentation said that the SWXCR battery backup protects a 4MB
cache for 20 hours; I don't recall seeing how long it protects a 32MB
cache. If a power failure should come along that lasts longer than the
time that the battery protects the data, the customer must be prepared
to restore from backup, because some random data or metadata may be
wrong on the disk (ouch!).
Using a write-back cache is much less beneficial in a mixed workload
than in a pure workload of random writes. If you're doing some
sequential writes, some reads, and using lots of disks simultaneously,
the benefits of the write-back cache will tend to disappear. (I wrote
a little article on this a while back and will try to add it to my web
page soon.)
If it were my system, I would try to figure out which disks - if any -
have a workload that resembles a pure random write scenario. I would
then try to figure out what the restore procedure would be for those
disks in the event of a power failure that lasts longer than the
battery backup period. Then, and only then, would I enable write back
caching, and ONLY for those particular disks.
/John Henning
CSD Performance Group
Digital Internal Use Only homepage: http://tlg-www.zko.dec.com/~henning
|
| The use of write back cache can be a touchy issue, and
(as was mentioned) has several data integrity issues
associated with it.
However, that aside, Digital UNIX does support devices
with NON-VOLATILE write back cache. That means HSZ*
family (with batteries), and SWXCR adapters (with batteries).
One difference between these 2 types of batteries is that
the HSZ knows if the battery looses power and therefore if
the cached data has been lost. The SWXCR doesn't.
Fred Knight
|