From: Phillip Susi <psusi@ubuntu.com>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu, sandeen@redhat.com
Subject: Re: [RESEND] [PATCH 2/2 v2] e2fsck: Do not forget to discard last block group
Date: Mon, 27 Feb 2012 11:35:38 -0500 [thread overview]
Message-ID: <4F4BB0DA.2060906@ubuntu.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1202270807030.5597@dhcp-27-109.brq.redhat.com>
On 2/27/2012 2:39 AM, Lukas Czerner wrote:
> I think that no one would ever install their file system on thinly
> provisioned storage just with dd. That's just stupid.
It could be on an SSD. It also could have been transferred with e2image
or similar imaging tools. While foolish to use dd, correcting that
foolishness seems to be the point of e2fsck -E discard. If you could
always rely on parts of the disk being discarded when they should, then
you wouldn't need e2fsck to do it would you?
> I have never said anything about the block group containing zeros. You
> do not even have this guarantee when using discard command.
You do with some disks, and sparse image files. My point was that the
uninitialized flag is no guarantee that the blocks are discarded. If
e2fsck -E discard is to clean up blocks that *should* be discarded, but
( for whatever reason ) aren't, then that should include uninitialized
groups.
> I am not really sure how this is relevant to the e2fsck doing discard. I
> just said that *if* the block group is market as UNINIT, then it was not
> used by the file system from the time of mke2fs, hence there should be
> nothing to reclaim.
There is something to reclaim if it was not discarded at mkfs time.
Think of an SSD that was formatted before mke2fs supported discard, and
had previously been dirtied by another fs.
> However this would only make sense to do in kernel, because in e2fsck it
> would not actually speed up anything until the next e2fsck call. But by
> that time the groups might be initialized again. To do this in kernel we
> would have to check whether the group is actually empty when freeing
> blocks, or freeing inodes. That code is not there, and I am not sure if
> it is worth the hassle (it might be), so I think that this patch is fine
> as it is.
If it may be a good idea to to have the kernel do this in the future,
then wouldn't it be prudent to allow for it now?
next prev parent reply other threads:[~2012-02-27 16:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-24 8:34 [RESEND] [PATCH 1/2 v2] e2fsck: Discard only unused parts of inode table Lukas Czerner
2012-02-24 8:34 ` [RESEND] [PATCH 2/2 v2] e2fsck: Do not forget to discard last block group Lukas Czerner
2012-02-24 14:46 ` Phillip Susi
2012-02-24 14:57 ` Lukas Czerner
2012-02-24 15:56 ` Phillip Susi
2012-02-24 16:13 ` Lukas Czerner
2012-02-24 16:48 ` Phillip Susi
2012-02-27 7:39 ` Lukas Czerner
2012-02-27 16:35 ` Phillip Susi [this message]
2012-02-27 17:00 ` Ted Ts'o
2012-02-27 17:57 ` Lukas Czerner
2012-02-27 18:05 ` Ted Ts'o
2012-02-27 18:33 ` Lukas Czerner
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=4F4BB0DA.2060906@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
/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