Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id AEF4063262D for ; Thu, 3 Jun 2010 16:31:38 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 75979-02 for ; Thu, 3 Jun 2010 19:31:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mail.postgresql.org (Postfix) with ESMTP id 1444D632726 for ; Thu, 3 Jun 2010 16:31:28 -0300 (ADT) Received: from [192.168.0.105] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0M8dKp-1PGVA70kPD-00vpCf; Thu, 03 Jun 2010 21:31:25 +0200 Message-ID: <4C08030A.20801@2ndquadrant.com> Date: Thu, 03 Jun 2010 15:31:22 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Scott Marlowe CC: Kevin Grittner , Craig James , Matthew Wakeling , pgsql-performance@postgresql.org Subject: Re: Weird XFS WAL problem References: <4C06E994.2080905@emolecules.com> <4C06EC01.3060506@catalyst.net.nz> <4C07E103.9020909@emolecules.com> <4C07A0830200002500031E74@gw.wicourts.gov> <4C07F1FA.8010909@2ndquadrant.com> <4C07B0D30200002500031EAA@gw.wicourts.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18Uz4huoKM9wJK4S13uQ6g/VXdaYAkpL1Mknkv bDEq4b2uLh++IeRoWe8eYNBCf0vMDILA2NrIqM+wOsQri4rPBW ZJHUuGKBz5RWySZHcHabD8om1XfDSrm X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.8 tagged_above=-10 required=5 tests=BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201006/66 X-Sequence-Number: 38922 Scott Marlowe wrote: > I think it's a case of the quickest, simplest answer to semi-new tech. > Not sure what to do with barriers? Just flush the whole cache. > Well, that really is the only useful thing you can do with regular SATA drives; the ATA command set isn't any finer grained than that in a way that's useful for this context. And it's also quite reasonable for a RAID controller to respond to that "flush the whole cache" call by flushing its cache. So it's not just the simplest first answer, I believe it's the only answer until a better ATA command set becomes available. I think this can only be resolved usefully for all of us at the RAID firmware level. If the controller had some logic that said "it's OK to not flush the cache when that call comes in if my battery is working fine", that would make this whole problem go away. I don't expect it's possible to work around the exact set of concerns Kevin listed any other way, because as he pointed out the right thing to do is very dependent on the battery health, which the OS also doesn't know (again, would require some new command set verbage). -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us