Re: Weird XFS WAL problem

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Craig James <craig_james(at)emolecules(dot)com>, Matthew Wakeling <matthew(at)flymine(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Weird XFS WAL problem
Date: 2010-06-04 15:06:39
Message-ID: 201006041506.o54F6dE05771@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Greg Smith wrote:
> 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.

Well, this is depressing. Now that we finally have common
battery-backed cache RAID controller cards, the file system developers
have throw down another roadblock in ext4 and xfs. Do we need to
document this?

On another topic, I am a little unclear on how things behave when the
drive is write-back. If the RAID controller card writes to the drive,
but the data isn't on the platers, how does it know when it can discard
that information from the BBU RAID cache?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2010-06-04 15:16:41 Re: Weird XFS WAL problem
Previous Message Andres Freund 2010-06-04 14:33:22 Re: How filesystems matter with PostgreSQL