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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
