From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
To: Bruno Wolff III <bruno@wolff.to>
Subject: Re: File Systems Compared
Date: Thu, 14 Dec 2006 13:21:11 -0800
Message-ID: <4581C047.8010208@cheapcomplexdevices.com> (raw)
In-Reply-To: <20061214174809.GA26057@wolff.to>
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>
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: rm_pg@cheapcomplexdevices.com, bruno@wolff.to
Subject: Re: File Systems Compared
In-Reply-To: <4581C047.8010208@cheapcomplexdevices.com>
* 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