[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120627193034.GA3198@thunk.org>
Date: Wed, 27 Jun 2012 15:30:34 -0400
From: Theodore Ts'o <tytso@....edu>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Ric Wheeler <ricwheeler@...il.com>, 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 Tue, Jun 26, 2012 at 04:44:08PM -0400, Eric Sandeen wrote:
> >
> > I tried running this fio recipe on v3.3, which I think does a decent job of
> > emulating the situation (fallocate 1G, do random 1M writes into it, with
> > fsyncs after each):
> >
> > [test]
> > filename=testfile
> > rw=randwrite
> > size=1g
> > filesize=1g
> > bs=1024k
> > ioengine=sync
> > fallocate=1
> > fsync=1
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
- Ted
--
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