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: Fri, 24 Feb 2012 11:48:32 -0500 [thread overview]
Message-ID: <4F47BF60.2080303@ubuntu.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1202241710190.13074@dhcp-27-109.brq.redhat.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2/24/2012 11:13 AM, Lukas Czerner wrote:
> It does not work that way, uinit is never set back. If it has been
> formated without discard it is user choice, moving the image to
> the thinly provisioned device, or ssd with dd is really bad idea
> anyway. That said, UNINIT means that it has not been used and hence
> there should be nothing to reclaim.
I could have sworn that e2fsck set it back when the block group became
free again, since there is once again no need to parse the bitmap and
you can just assume it's empty without having to read it. I certainly
have e2defrag doing this. If fsck and the kernel currently don't do
this, they should.
Whether it is a bad idea or not, people do move filesystems around and
have existing systems formatted before mke2fs would issue discards, so
it is a good idea to discard unused areas regardless of whether or not
they are uninitialized.
My understanding of uninitialized is that it was added as an
optimization meaning "there's nothing here, so you can skip/ignore
this" rather than "this has _never_ been used, so you can rely on it
containing all zeros and being discarded".
Indeed, a quick test filling a block device with random data and
running mke2fs on it leaves the random data in the uninitialized block
bitmaps rather than writing all zeros.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPR79fAAoJEJrBOlT6nu75K8QH/RJoNQPm+rGtmv1cmWPusuNb
pb/6hRmOhsIUClaMn2diinGgH7HQbZ9FqsSx0mZmWq52T/21korGk3fyVe/nfL9m
h4xFYJLNEdsSCJE7mcpUu5BMxCwlYEcybHu7xobVtqHlF671zjszj/xCGBgQIEwD
3tRu8JXc/grnrya0CxDXd5kenM6oQviEmkproYUjG21XW+2DKjgHD1w6lbcHZHw5
5fvWVwFOMy9OgagcBzAxo43E7oZoPCD6o54HT8As7FoBfUSt9Z4GLMe3ULH4SbpP
KKuRiumOnBW9fz7I3jRDkVpJ+9MxWqpUL4SA79sDreYfOBAa6m7cOaR+PHr8sTM=
=8u4o
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2012-02-24 16:48 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 [this message]
2012-02-27 7:39 ` Lukas Czerner
2012-02-27 16:35 ` Phillip Susi
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=4F47BF60.2080303@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