From: Tom Lane <tgl@sss.pgh.pa.us>
To: tv@fuzzy.cz
Cc: Greg Smith <greg@2ndQuadrant.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: strange pgbench results (as if blocked at the end)
Date: Sun, 14 Aug 2011 13:33:44 -0400
Message-ID: <28386.1313343224@sss.pgh.pa.us> (raw)
In-Reply-To: <bdf03aa0550140de6491b3ce6d3eebd4@mail.gransy.com>
References: <2f9ba8ed6e4ed11d9a6d236cb4d2a2ec.squirrel@sq.gransy.com>
<4E45EAD3.9030102@2ndQuadrant.com>
<bdf03aa0550140de6491b3ce6d3eebd4@mail.gransy.com>
<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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, tv@fuzzy.cz, greg@2ndQuadrant.com
Subject: Re: strange pgbench results (as if blocked at the end)
In-Reply-To: <28386.1313343224@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox