From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
To: Greg Smith <gsmith@gregsmith.com>
Cc: 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 21:33:28 -0700
Message-ID: <48A50718.5000500@cheapcomplexdevices.com> (raw)
In-Reply-To: <Pine.GSO.4.64.0808140825330.26747@westnet.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>
<Pine.GSO.4.64.0808140825330.26747@westnet.com>
Greg Smith wrote:
> On Wed, 13 Aug 2008, Ron Mayer wrote:
>
>> 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.
But only if you turn off IDE drive caches.
What was new to me in these experiments is that if you touch the
inode as described here:
http://article.gmane.org/gmane.linux.file-systems/21373
then fsync() works and you can leave the IDE cache enabled; so
long as your drive supports the flush command -- which you can
see by looking for the drive in the output of:
%dmesg | grep 'disabling barriers'
JBD: barrier-based sync failed on md1 - disabling barriers
JBD: barrier-based sync failed on hda3 - disabling barriers
>> 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
I almost fear I misphrased that. Apparently IDE drives
don't lie (the ones that don't support barriers let the OS
know that they don't). And apparently write barriers
do work.
It's just that ext3 only uses the write barriers correctly
on fsync() when an inode is touched, rather than any time
a file's data is touched.
> then it seems buggy. I personally just ignore the fact that they exist
> on ext3, and maybe one day ext4 will get this right.
+1
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, gsmith@gregsmith.com
Subject: Re: Filesystem benchmarking for pg 8.3.3 server
In-Reply-To: <48A50718.5000500@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