From: Bruno Wolff III <bruno@wolff.to>
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: File Systems Compared
Date: Fri, 15 Dec 2006 10:34:15 -0600
Message-ID: <20061215163415.GB26864@wolff.to> (raw)
In-Reply-To: <4581C047.8010208@cheapcomplexdevices.com>
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>
<20061214174809.GA26057@wolff.to>
<4581C047.8010208@cheapcomplexdevices.com>
The reply wasn't (directly copied to the performance list, but I will
copy this one back.
On Thu, Dec 14, 2006 at 13:21:11 -0800,
Ron Mayer <rm_pg@cheapcomplexdevices.com> wrote:
> Bruno Wolff III wrote:
> > 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).
>
> Is it true that some drives ignore this; or is it mostly
> an urban legend that was started by testers that didn't
> have kernels with write barrier support. I'd be especially
> interested in knowing if there are any currently available
> drives which ignore those commands.
>
> >>> 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.
>
> With XFS the default is apparently to enable write barrier
> support unless you explicitly disable it with the nobarrier mount option.
> It also will warn you in the system log if the underlying device
> doesn't have write barrier support.
>
> SGI recommends that you use the "nobarrier" mount option if you do
> have a persistent (battery backed) write cache on your raid device.
>
> http://oss.sgi.com/projects/xfs/faq.html#wcache
>
>
> >> 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.
>
> With write barriers, fsync() waits for the physical disk; but I believe
> the background writes from write() done by pdflush don't have to; so
> it's kinda like only disabling the cache for WAL files and the filesystem's
> journal, but having it enabled for the rest of your write activity (the
> tables except at checkpoints? the log file?).
>
> > 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.
> >
>
> Ugh. Looking for where that's documented; and hoping it is or will soon
> work on software 1+0 as well.
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, rm_pg@cheapcomplexdevices.com
Subject: Re: File Systems Compared
In-Reply-To: <20061215163415.GB26864@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