[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150523030553.GD2750@thunk.org>
Date: Fri, 22 May 2015 23:05:53 -0400
From: Theodore Ts'o <tytso@....edu>
To: Phil Susi <psusi@...ntu.com>
Cc: ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Unused block group, but all blocks not free?
On Fri, May 22, 2015 at 08:37:26AM -0400, Phil Susi wrote:
> On 5/21/2015 10:28 PM, Theodore Ts'o wrote:
> >On Thu, May 21, 2015 at 08:08:17PM -0400, Phillip Susi wrote:
> >The change was that for uninitialized block bitmaps, dumpe2fs used to
> >display incorrect information (that is, it would claim all of the
> >blocks were free, even though in fact that was not true).
>
> It seems to have actually been a change on disk, since e2defrag *used* to
> count the number of free blocks assuming an uninitialized bitmap meant that
> they were all free, and get the same number reported in the superblock.
> This was probably prior to the change you are thinking of.
The change was in libext2fs; it would actually initialize portion of
the bitmap coming from uninitialized block groups instead of actually
leaving that portion of the bitmap as all zero.
> IIRC, when I looked using debugfs, the block groups containing metadata
> always had their bitmaps initialized.
That's a different change. We checked that the kernel and e2fsprogs
was doing the right thing if block gorups containing metadata were
left uninitialized (and in fact had been doing the right thing for a
long time), and so we started allowing mke2fs to mark those block
groups as uninitialized.
We didn't check e2defrag because I didn't realize you had ressurected
it. (At least when I last looked at it, I was too scared about its
error handling, etc., and so I had deliberately declined to try to get
it into e2fsprogs as something I wasn't willing to support it. So you
are a braver person than I....)
- Ted
--
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