From: Greg Smith <greg@2ndquadrant.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Craig James <craig_james@emolecules.com>
Cc: Matthew Wakeling <matthew@flymine.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: Weird XFS WAL problem
Date: Sat, 05 Jun 2010 18:50:27 -0400
Message-ID: <4C0AD4B3.3020209@2ndquadrant.com> (raw)
In-Reply-To: <4C08D7070200002500031F66@gw.wicourts.gov>
References: <4C08D4380200002500031F5D@gw.wicourts.gov>
<201006041530.o54FUAQ09934@momjian.us>
<4C08D7070200002500031F66@gw.wicourts.gov>
Kevin Grittner wrote:
> I don't know at the protocol level; I just know that write barriers
> do *something* which causes our controllers to wait for actual disk
> platter persistence, while fsync does not
It's in the docs now:
http://www.postgresql.org/docs/9.0/static/wal-reliability.html
FLUSH CACHE EXT is the ATAPI-6 call that filesystems use to enforce
barriers on that type of drive. Here's what the relevant portion of the
ATAPI spec says:
"This command is used by the host to request the device to flush the
write cache. If there is data in the write
cache, that data shall be written to the media.The BSY bit shall remain
set to one until all data has been
successfully written or an error occurs."
SAS systems have a similar call named SYNCHRONIZE CACHE.
The improvement I actually expect to arrive here first is a reliable
implementation of O_SYNC/O_DSYNC writes. Both SAS and SATA drives that
capable of doing Native Command Queueing support a write type called
"Force Unit Access", which is essentially just like a direct write that
cannot be cached. When we get more kernels with reliable sync writing
that maps under the hood to FUA, and can change wal_sync_method to use
them, the need to constantly call fsync for every write to the WAL will
go away. Then the "blow out the RAID cache when barriers are on"
behavior will only show up during checkpoint fsyncs, which will make
things a lot better (albeit still not ideal).
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
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: greg@2ndquadrant.com, Kevin.Grittner@wicourts.gov, bruce@momjian.us, craig_james@emolecules.com, matthew@flymine.org
Subject: Re: Weird XFS WAL problem
In-Reply-To: <4C0AD4B3.3020209@2ndquadrant.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