[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120229140549.GC5054@shiny>
Date: Wed, 29 Feb 2012 09:05:49 -0500
From: Chris Mason <chris.mason@...cle.com>
To: Jacek Luczak <difrost.kernel@...il.com>
Cc: linux-ext4@...r.kernel.org,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, linux-btrfs@...r.kernel.org,
Al Viro <viro@...iv.linux.org.uk>, "Ted Ts'o" <tytso@....edu>
Subject: Re: getdents - ext4 vs btrfs performance
On Wed, Feb 29, 2012 at 08:51:58AM -0500, Chris Mason wrote:
> On Wed, Feb 29, 2012 at 02:31:03PM +0100, Jacek Luczak wrote:
> > Ext4 results:
> > | Type | 2.6.39.4-3 | 3.2.7
> > | Dir cnt | 17m 40sec | 11m 20sec
> > | File cnt | 17m 36sec | 11m 22sec
> > | Copy | 1h 28m | 1h 27m
> > | Remove| 3m 43sec
>
> Are the btrfs numbers missing? ;)
[ answered in a different reply, btrfs is faster in everything except
delete ]
The btrfs readdir uses an index that is much more likely to be
sequential on disk than ext. This makes the readdir more sequential and
it makes the actual file IO more sequential because we're reading things
in the order they were created instead of (random) htree index order.
>
> In order for btrfs to be faster for cp -a, the files probably didn't
> change much since creation. Btrfs maintains extra directory indexes
> that help in sequential backup scans, but this usually means slower
> delete performance.
>
> But, how exactly did you benchmark it? If you compare a fresh
> mkfs.btrfs where you just copied all the data over with an ext4 FS that
> has been on the disk for a long time, it isn't quite fair to ext4.
>
But, the consistent benchmarking part is really important. We shouldn't
put an aged ext4 up against a fresh mkfs.btrfs. Did you do ext4
comparisons on a fresh copy?
-chris
--
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