[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F4BB0DA.2060906@ubuntu.com>
Date: Mon, 27 Feb 2012 11:35:38 -0500
From: Phillip Susi <psusi@...ntu.com>
To: Lukas Czerner <lczerner@...hat.com>
CC: linux-ext4@...r.kernel.org, tytso@....edu, sandeen@...hat.com
Subject: Re: [RESEND] [PATCH 2/2 v2] e2fsck: Do not forget to discard last
block group
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?
--
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
Powered by blists - more mailing lists