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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
