On Tuesday 17 August 2010 10:29:10 Greg Smith wrote:
> Andres Freund wrote:
> > An fsync() equals a barrier so it has the effect of stopping
> > reordering around it - especially on systems with larger multi-disk
> > arrays thats pretty expensive.
> > You can achieve surprising speedups, at least in my experience, by
> > forcing the kernel to start writing out pages *without enforcing
> > barriers* first and then later enforce a barrier to be sure its
> > actually written out.
>
> Standard practice on high performance systems with good filesystems and
> a battery-backed controller is to turn off barriers anyway. That's one
> of the first things to tune on XFS for example, when you have a reliable
> controller. I don't have enough data on ext4 to comment on tuning for
> it yet.
>
> The sole purpose for the whole Linux write barrier implementation in my
> world is to flush the drive's cache, when the database does writes onto
> cheap SATA drives that will otherwise cache dangerously. Barriers don't
> have any place on a serious system that I can see. The battery-backed
> RAID controller you have to use to make fsync calls fast anyway can do
> some simple write reordering, but the operating system doesn't ever have
> enough visibility into what it's doing to make intelligent decisions
> about that anyway.
Even if were not talking about a write barrier in an "ensure its written out
of the cache" way it still stops the io-scheduler from reordering. I
benchmarked it (custom app) and it was very noticeable on a bunch of different
systems (with a good BBUed RAID).
Andres