From: Eric Sandeen <sandeen@redhat.com>
To: Karsten Weiss <K.Weiss@science-computing.de>
Cc: Dmitry Monakhov <dmonakhov@openvz.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: Bad ext4 sync performance on 16 TB GPT partition
Date: Mon, 01 Mar 2010 10:22:06 -0600 [thread overview]
Message-ID: <4B8BE9AE.5080601@redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1003010908360.26560@wong.science-computing.de>
Karsten Weiss wrote:
> Hi Eric,
>
> On Fri, 26 Feb 2010, Eric Sandeen wrote:
>
>>> => The problem shows only with the CentOS / Red Hat 5.4 kernels (including
>>> RH's test kernel 2.6.18-190.el5). Aadmittedly ext4 is only a technology
>>> preview in 5.4...
>>>
>>> I've also tried the latest CentOS 5.3 kernel-2.6.18-128.7.1.el5 but
>>> couldn't mount the device (with -t ext4dev).
>>>
>>> 2.6.18-164.el5 (the initial CentOS 5.4 kernel) has the bug, too.
>>>
>>> I'm willing to test patches if somebody wants to debug the problem.
>> Ok, that's interesting. We've not had bona-fide RHEL customers report
>> the problem, but then maybe it hasn't been tested this way.
>
> I think so because, as I mentioned, the issue can be reproduced with the
> RH test kernel 2.6.18-190.el5 x86_64 (http://people.redhat.com/jwilson/el5/),
> too.
>
>> 2.6.18-178.el5 and beyond is based on the 2.6.32 codebase for ext4.
>>
>> Testing generic 2.6.32 might also be interesting as a datapoint,
>> if you're willing.
>
> Sorry for the delay, here's the (good) 2.6.32 result:
>
> # /usr/bin/time bash -c "dd if=/dev/zero of=/mnt/large/10GB bs=1M count=10000 && sync"
> 10000+0 records in
> 10000+0 records out
> 10485760000 bytes (10 GB) copied, 46.3369 seconds, 226 MB/s
> 0.00user 14.17system 0:59.53elapsed 23%CPU (0avgtext+0avgdata 6224maxresident)k
> 0inputs+0outputs (0major+1045minor)pagefaults 0swaps
>
> To summarize:
>
> Bad: 2.6.18-164.el5 (CentOS)
> Bad: 2.6.18-164.11.1el5 (CentOS)
> Bad: 2.6.18-190.el5 (RH)
> Good: 2.6.32
> Good: 2.6.33
>
Thanks, I'll have to investigate that. I guess something may have gotten lost
in translation in the 2.6.32->2.6.18 backport.....
-Eric
next prev parent reply other threads:[~2010-03-01 16:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-26 10:18 Bad ext4 sync performance on 16 TB GPT partition Karsten Weiss
2010-02-26 11:33 ` Karsten Weiss
2010-02-26 11:46 ` Dmitry Monakhov
2010-02-26 15:47 ` Karsten Weiss
2010-02-26 17:49 ` Eric Sandeen
2010-03-01 8:57 ` Karsten Weiss
2010-03-01 16:22 ` Eric Sandeen [this message]
2010-03-12 11:37 ` Karsten Weiss
2010-03-12 15:20 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B8BE9AE.5080601@redhat.com \
--to=sandeen@redhat.com \
--cc=K.Weiss@science-computing.de \
--cc=dmonakhov@openvz.org \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.