From: Ted Ts'o <tytso@mit.edu>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 4/4 v2] ext4: Do not discard group with BLOCK_UNINIT set
Date: Tue, 6 Mar 2012 17:18:15 -0500 [thread overview]
Message-ID: <20120306221815.GA5472@thunk.org> (raw)
In-Reply-To: <1330690318-22627-4-git-send-email-lczerner@redhat.com>
On Fri, Mar 02, 2012 at 01:11:58PM +0100, Lukas Czerner wrote:
> Because the BLOCK_UNINIT is only set on mke2fs time and cleared when
> allocation from that group takes place we know that when set, there was
> not anything allocated from that group, hence there should not be anything
> to discard from the file system point of view.
There's a really good reason to set BLOCK_UNINIT once we have noticed
that all of the blocks in the block group have been released....
If you have a 3TB HDD, running e2fsck takes 4 times as long if all of
the block groups have BLOCK_UNINIT cleared, compared to a freshly
mkfs'ed file system. As a result of my getting really annoyed at how
long it took in this case, I'm planning on making e2fsck clear
BLOCK_UNINIT if possible, so that subsequent e2fsck's (and dumpe2fs
and debugfs invocations) can also be fast.
- Ted
next prev parent reply other threads:[~2012-03-06 22:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-02 12:11 [PATCH 1/4 v2] ext4: fix start and len arguments handling in ext4_trim_fs() Lukas Czerner
2012-03-02 12:11 ` [PATCH 2/4 v2] ext4: Fix trimmed block count computing Lukas Czerner
2012-03-05 12:38 ` Jan Kara
2012-03-22 1:22 ` Ted Ts'o
2012-03-02 12:11 ` [PATCH 3/4 v2] ext4: Always set then trimmed blocks count into len Lukas Czerner
2012-03-05 12:38 ` Jan Kara
2012-03-22 1:23 ` Ted Ts'o
2012-03-02 12:11 ` [PATCH 4/4 v2] ext4: Do not discard group with BLOCK_UNINIT set Lukas Czerner
2012-03-05 12:41 ` Jan Kara
2012-03-05 13:12 ` Lukas Czerner
2012-03-06 22:18 ` Ted Ts'o [this message]
2012-03-07 7:10 ` Lukas Czerner
2012-03-07 17:22 ` Ted Ts'o
2012-03-05 12:37 ` [PATCH 1/4 v2] ext4: fix start and len arguments handling in ext4_trim_fs() Jan Kara
2012-03-22 1:22 ` Ted Ts'o
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=20120306221815.GA5472@thunk.org \
--to=tytso@mit.edu \
--cc=lczerner@redhat.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.