Kevin Grittner wrote:
I've seen this, too (with xfs). Our RAID controller, in spite of
having BBU cache configured for writeback, waits for actual
persistence on disk for write barriers (unlike for fsync). This
does strike me as surprising to the point of bordering on qualifying
as a bug.
Completely intentional, and documented at
http://xfs.org/index.php/XFS_FAQ#Q._Should_barriers_be_enabled_with_storage_which_has_a_persistent_write_cache.3F
The issue is that XFS will actually send the full "flush your cache"
call to the controller, rather than just the usual fsync call, and that
eliminates the benefit of having a write cache there in the first
place. Good controllers respect that and flush their whole write cache
out. And ext4 has adopted the same mechanism. This is very much a good
thing from the perspective of database reliability for people with
regular hard drives who don't have a useful write cache on their cheap
hard drives. It allows them to keep the disk's write cache on for other
things, while still getting the proper cache flushes when the database
commits demand them. It does mean that everyone with a non-volatile
battery backed cache, via RAID card typically, needs to turn barriers
off manually.
I've already warned on this list that PostgreSQL commit performance on
ext4 is going to appear really terrible to many people. If you
benchmark and don't recognize ext3 wasn't operating in a reliable mode
before, the performance drop now that ext4 is doing the right thing with
barriers looks impossibly bad.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@xxxxxxxxxxxxxxx www.2ndQuadrant.us
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
