[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FF1CD5D.8010904@redhat.com>
Date: Mon, 02 Jul 2012 11:33:33 -0500
From: Eric Sandeen <sandeen@...hat.com>
To: "Theodore Ts'o" <tytso@....edu>, Fredrick <fjohnber@...o.com>,
Ric Wheeler <rwheeler@...hat.com>, linux-ext4@...r.kernel.org,
Andreas Dilger <adilger@...ger.ca>, wenqing.lz@...bao.com
Subject: Re: ext4_fallocate
On 07/01/2012 10:16 PM, Zheng Liu wrote:
> On Wed, Jun 27, 2012 at 07:02:45PM -0400, Eric Sandeen wrote:
>> On 6/27/12 3:30 PM, Theodore Ts'o wrote:
>>> A better workload would be to use a blocksize of 4k. By using a
>>> blocksize of 1024k, it's not surprising that the metadata overhead is
>>> in the noise.
>>>
>>> Try something like this; this will cause the extent tree overhead to
>>> be roughly equal to the data block I/O.
>>>
>>> [global]
>>> rw=randwrite
>>> size=128m
>>> filesize=1g
>>> bs=4k
>>> ioengine=sync
>>> fallocate=1
>>> fsync=1
>>>
>>> [thread1]
>>> filename=testfile
>
> Hi Eric,
>
> Could you please run this test with 'journal_async_commit' flag. In my
> previous test, this feature can dramatically improve the performance of
> uninitialized extent conversion.
>
> I have sent an email to do a similar test [1]. In that email, I do a
> similar test and the journal_async_commit flag quite can improve the
> performance.
I can try to find time for that, but so far I haven't actually seen any
severe impact of conversion on a non-debug kernel. And didn't Jan think
that journal_async_commit was fatally flawed?
At this point I think it is up to the proponents of the
expose-stale-data patch to document & demonstrate the workload which
justifies such a change...
-Eric
> 1. http://comments.gmane.org/gmane.linux.file-systems/63569
>
> Regards,
> Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists