Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 11A55B5DBE9 for ; Mon, 15 Aug 2011 17:36:58 -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 09749-04 for ; Mon, 15 Aug 2011 20:36:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mail.postgresql.org (Postfix) with ESMTP id B213EB5D803 for ; Mon, 15 Aug 2011 17:36:51 -0300 (ADT) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LmPME-1RSfdT3a4I-00a1KJ; Mon, 15 Aug 2011 22:36:50 +0200 Message-ID: <4E498361.6030408@2ndQuadrant.com> Date: Mon, 15 Aug 2011 16:36:49 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110702 Icedove/3.0.11 MIME-Version: 1.0 To: Tom Lane CC: tv@fuzzy.cz, pgsql-performance@postgresql.org Subject: Re: strange pgbench results (as if blocked at the end) References: <2f9ba8ed6e4ed11d9a6d236cb4d2a2ec.squirrel@sq.gransy.com> <4E45EAD3.9030102@2ndQuadrant.com> <28386.1313343224@sss.pgh.pa.us> In-Reply-To: <28386.1313343224@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:y/wMfg7a3GXenRoXc7xH414CEITeBxU+xJTdhzhUWJr n2GMC5wUFBomac/sE6ucKBr5reUULTGxT6AtIKX8DPagH1YmJ8 QYLY6VvamMiQkMj5w62W6nRC8nQPiEVQgaJKn7GvCtTc3tkmxV A3iLLG2E3pk6gFN6Q0N/fW5T01B1RdUAbOrmh2i2pp1HeE4Tjj J/UAhfWj6ENyLUHyfj07nlKKQs0q3m/jsbdpTAnp0c= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201108/164 X-Sequence-Number: 44611 On 08/14/2011 01:33 PM, Tom Lane wrote: > (The changes in question were purely for performance, and involved a > conversion from write barriers in the block layer to flush+fua, whatever > that is.) Furthermore, this affected every filesystem not only ext4, > so it really entirely fails to support Greg's argument. > FUA is "Force Unit Access", shorthand for forcing write-through. If you're staring at this from the perspective I am, where I assume that every line of new filesystem code always takes a while from release until it's stable, it still concerns me. I suspect that both of these code paths--the write barrier one and the flush+FUA one--are fine on XFS. One of the reasons XFS was so terrible in its early years was because it took a long time to get those parts in particular correct, which was complicated by how badly drives lied about everything back then. If these changes shift around which section of the ext4 write path code are exercised, it could easily be the case that it moves fsync related work (which has been one of the buggiest parts of that filesystem) from code that has been tested heavily to parts that haven't been hit as hard yet by users. My paranoid raving about this particular bug isn't strongly supported; I'll concede that with the additional data you've provided. But I don't think it's completely unfounded either. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us