On Dec 11, 2006, at 12:54 PM, Bruno Wolff III wrote:
On Wed, Dec 06, 2006 at 08:55:14 -0800,
Mark Lewis <mark.lewis@xxxxxxxx> wrote:
Anyone run their RAIDs with disk caches enabled, or is this akin to
having fsync off?
Disk write caches are basically always akin to having fsync off. The
only time a write-cache is (more or less) safe to enable is when
it is
backed by a battery or in some other way made non-volatile.
So a RAID controller with a battery-backed write cache can enable its
own write cache, but can't safely enable the write-caches on the disk
drives it manages.
This appears to be changing under Linux. Recent kernels have write
barriers
implemented using cache flush commands (which some drives ignore,
so you
need to be careful). In very recent kernels, software raid using
raid 1
will also handle write barriers. To get this feature, you are
supposed to
mount ext3 file systems with the barrier=1 option. For other file
systems,
the parameter may need to be different.
But would that actually provide a meaningful benefit? When you
COMMIT, the WAL data must hit non-volatile storage of some kind,
which without a BBU or something similar, means hitting the platter.
So I don't see how enabling the disk cache will help, unless of
course it's ignoring fsync.
Now, I have heard something about drives using their stored
rotational energy to flush out the cache... but I tend to suspect
urban legend there...
--
Jim Nasby jim@xxxxxxxxx
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
