From: Greg Smith <gsmith@gregsmith.com>
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Filesystem benchmarking for pg 8.3.3 server
Date: Thu, 14 Aug 2008 10:10:24 -0400 (EDT)
Message-ID: <Pine.GSO.4.64.0808140825330.26747@westnet.com> (raw)
In-Reply-To: <48A36090.6070309@cheapcomplexdevices.com>
References: <32A7A76B-16CA-4CDB-AD43-973AD6A3FC7B@mac.se>
<Pine.GSO.4.64.0808081835320.21924@westnet.com>
<48A2050D.4050803@cheapcomplexdevices.com>
<Pine.GSO.4.64.0808130150510.9761@westnet.com>
<48A2F297.9030703@cheapcomplexdevices.com>
<dcc563d10808130748m3a8fe7f8n2a64965990317697@mail.gmail.com>
<48A36090.6070309@cheapcomplexdevices.com>
On Wed, 13 Aug 2008, Ron Mayer wrote:
> First off - some IDE drives don't even support the relatively recent ATA
> command that apparently lets the software know when a cache flush is
> complete.
Right, so this is one reason you can't assume barriers will be available.
And barriers don't work regardless if you go through the device mapper,
like some LVM and software RAID configurations; see
http://lwn.net/Articles/283161/> Second of all - ext3 fsync() appears to me to be *extremely* stupid.
> It only seems to correctly do the correct flushing (and waiting) for a
> drive's cache to be flushed when a file's inode has changed.
This is bad, but the way PostgreSQL uses fsync seems to work fine--if it
didn't, we'd all see unnaturally high write rates all the time.
> So I take back what I said about linux and write barriers
> being sane. They're not.
Right. Where Linux seems to be at right now is that there's this
occasional problem people run into where ext3 volumes can get corrupted if
there are out of order writes to its journal:
http://en.wikipedia.org/wiki/Ext3#No_checksumming_in_journalhttp://archives.free.net.ph/message/20070518.134838.52e26369.en.html
(By the way: I just fixed the ext3 Wikipedia article to reflect the
current state of things and dumped a bunch of reference links in to there,
including some that are not listed here. I prefer to keep my notes about
interesting topics in Wikipedia instead of having my own copies whenever
possible).
There are two ways to get around this issue ext3. You can disable write
caching, changing your default mount options to "data=journal". In the
PostgreSQL case, the way the WAL is used seems to keep corruption at bay
even with the default "data=ordered" case, but after reading up on this
again I'm thinking I may want to switch to "journal" anyway in the future
(and retrofit some older installs with that change). I also avoid using
Linux LVM whenever possible for databases just on general principle; one
less flakey thing in the way.
The other way, barriers, is just plain scary unless you know your disk
hardware does the right thing and the planets align just right, and even
then it seems buggy. I personally just ignore the fact that they exist on
ext3, and maybe one day ext4 will get this right.
By the way: there is a great ext3 "torture test" program that just came
out a few months ago that's useful for checking general filesystem
corruption in this context I keep meaning to try, if you've got some
cycles to spare working in this area check it out:
http://uwsg.indiana.edu/hypermail/linux/kernel/0805.2/1470.html
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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: gsmith@gregsmith.com, rm_pg@cheapcomplexdevices.com
Subject: Re: Filesystem benchmarking for pg 8.3.3 server
In-Reply-To: <Pine.GSO.4.64.0808140825330.26747@westnet.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