To: tv@fuzzy.cz
cc: "Greg Smith" <greg@2ndQuadrant.com>, pgsql-performance@postgresql.org
Subject: Re: strange pgbench results (as if blocked at the end) 
In-reply-to: <bdf03aa0550140de6491b3ce6d3eebd4@mail.gransy.com> 
References: <2f9ba8ed6e4ed11d9a6d236cb4d2a2ec.squirrel@sq.gransy.com>
	<4E45EAD3.9030102@2ndQuadrant.com>
	<bdf03aa0550140de6491b3ce6d3eebd4@mail.gransy.com>
Comments: In-reply-to <tv@fuzzy.cz>
	message dated "Sun, 14 Aug 2011 14:51:37 +0200"
Date: Sun, 14 Aug 2011 13:33:44 -0400
Message-ID: <28386.1313343224@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

<tv@fuzzy.cz> writes:
> On 13 Srpen 2011, 5:09, Greg Smith wrote:
>> And I keep seeing too many data corruption issues on ext4 to recommend
>> anyone use it yet for PostgreSQL, that's why I focused on XFS.  ext4
>> still needs at least a few more months before all the bug fixes it's
>> gotten in later kernels are backported to the 2.6.32 versions deployed
>> in RHEL6 and Debian Squeeze, the newest Linux distributions my customers
>> care about right now.  On RHEL6 for example, go read
>> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.1_Technical_Notes/kernel.html
>> , specifically BZ#635199, and you tell me if that sounds like it's
>> considered stable code yet or not.  "The block layer will be updated in
>> future kernels to provide this more efficient mechanism of ensuring
>> ordering...these future block layer improvements will change some kernel
>> interfaces..."  Yikes, that does not inspire confidence to me.

> XFS is naturally much more mature / stable than EXT4, but I'm not quite
> sure I want to judge the stability of code based on a comment in release
> notes. As I understand it, the comment says something like "things are
> not working as efficiently as it should, we'll improve that in the
> future" and it relates to the block layer as a whole, not just specific
> file systems. But I don't have access to the bug #635199, so maybe I
> missed something.

I do ;-).  The reason for the tech note was to point out that RHEL6.1
would incorporate backports of upstream kernel changes that broke the
ABI for loadable kernel modules, compared to what it had been in
RHEL6.0.  That's of great interest to third-party software developers
who add device or filesystem drivers to RHEL, but I don't think it
speaks at all to whether the code is unstable from a user's standpoint.
(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.

			regards, tom lane