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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.