From: Bruno Wolff III <bruno@wolff.to>
To: Jim Nasby <decibel@decibel.org>
Cc: Mark Lewis <mark.lewis@mir3.com>
Cc: Brian Wipf <brian@clickspace.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: File Systems Compared
Date: Thu, 14 Dec 2006 11:48:09 -0600
Message-ID: <20061214174809.GA26057@wolff.to> (raw)
In-Reply-To: <FB83EA45-E67F-45EA-9F90-F1F075FA93A6@decibel.org>
References: <BEB285F8-0BD2-4524-BD46-B1D35E7EFBEB@clickspace.com>
<82bqmh3rfc.fsf@mid.bfk.de>
<1165424114.9734.298.camel@archimedes>
<20061211175411.GA3236@wolff.to>
<FB83EA45-E67F-45EA-9F90-F1F075FA93A6@decibel.org>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: bruno@wolff.to, decibel@decibel.org, mark.lewis@mir3.com, brian@clickspace.com
Subject: Re: File Systems Compared
In-Reply-To: <20061214174809.GA26057@wolff.to>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox