On Thu, Dec 14, 2006 at 01:39:00 -0500,
Jim Nasby <decibel@decibel.org> wrote:
> On Dec 11, 2006, at 12:54 PM, Bruno Wolff III wrote:
> >
> >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.
When you do an fsync, the OS sends a cache flush command to the drive,
which on most drives (but supposedly there are ones that ignore this
command) doesn't return until all of the cached pages have been written
to the platter, and doesn't return from the fsync until the flush is complete.
While this writes more sectors than you really need, it is safe. And it allows
for caching to speed up some things (though not as much as having queued
commands would).
I have done some tests on my systems and the speeds I am getting make it
clear that write barriers slow things down to about the same range as having
caches disabled. So I believe that it is likely working as advertised.
Note the use case for this is more for hobbiests or development boxes. You can
only use it on software raid (md) 1, which rules out most "real" systems.