Abhishek Rai wrote: > This patch modifies the block allocation strategy in ext3 in order to > improve fsck performance. This was initially sent out as a patch for > ext2, but given the lack of ongoing development on ext2, I have > crossported it to ext3 instead. Slow fsck is not a serious problem on > ext3 due to journaling, but once in a while users do need to run full > fsck on their ext3 file systems. This can be due to several reasons: > (1) bad disk, bad crash, etc, (2) bug in jbd/ext3, and (3) every few > reboots, it's good to run fsck anyway. This patch will help reduce > full fsck time for ext3. I've seen 50-65% reduction in fsck time when > using this patch on a near-full file system. With some fsck > optimizations, this figure becomes 80%. For what it's worth, this speeds large file removals, too: http://people.redhat.com/esandeen/rm_test/ext3_metacluster_rm.png http://people.redhat.com/esandeen/rm_test/ext3_rm.png That's 22s vs. 73s for a 56G file on a fresh 100G filesystem, removed after a fresh remount (cold cache). If I actually preload all of the indirect blocks (I used filefrag): http://people.redhat.com/esandeen/rm_test/ext3_preload_rm.png it comes in at 6 seconds... For comparison, stock ext4 from 2.6.25 clocks in at 6s, and xfs is basically instantaneous. (btrfs default is 6s, and btrfs with no data checksumming is on par with xfs). -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
