lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ