From: Eric Sandeen <sandeen@redhat.com>
To: Abhishek Rai <abhishekrai@google.com>
Cc: Andreas Dilger <adilger@sun.com>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] Clustering indirect blocks in Ext3 (was Ext2)
Date: Thu, 24 Apr 2008 16:10:33 -0500 [thread overview]
Message-ID: <4810F749.7000802@redhat.com> (raw)
In-Reply-To: <d9885f0f0710261658p218050d9mdf64714ddb8d47f1@mail.gmail.com>
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
next prev parent reply other threads:[~2008-04-24 21:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-26 23:58 [PATCH] Clustering indirect blocks in Ext3 (was Ext2) Abhishek Rai
2008-04-24 21:10 ` Eric Sandeen [this message]
2008-04-25 15:54 ` Eric Sandeen
2008-05-04 20:09 ` Mike Snitzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4810F749.7000802@redhat.com \
--to=sandeen@redhat.com \
--cc=abhishekrai@google.com \
--cc=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).