linux-ext4 - Re: [PATCH] Clustering indirect blocks in Ext3 (was Ext2)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4810F749.7000802@redhat.com>
Date:	Thu, 24 Apr 2008 16:10:33 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Abhishek Rai <abhishekrai@...gle.com>
CC:	Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] Clustering indirect blocks in Ext3 (was Ext2)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html