From: Theodore Ts'o <tytso@mit.edu>
To: Phillip Susi <psusi@ubuntu.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: Unused block group, but all blocks not free?
Date: Thu, 21 May 2015 19:59:40 -0400 [thread overview]
Message-ID: <20150521235940.GB2750@thunk.org> (raw)
In-Reply-To: <555D0541.1000804@ubuntu.com>
On Wed, May 20, 2015 at 06:05:53PM -0400, Phillip Susi wrote:
> On 05/20/2015 12:31 PM, Theodore Ts'o wrote:
> > As an optimization, if we can reconstruct the allocation bitmap from
> > the block group descriptors, we'll leave the block allocation bitmap
> > uninitialized, so that programs like e2fsck don't have to read the
> > bitmap block. For a mostly empty file system, this optimization is
> > quite noticeable.
>
> Ahh, so for block groups that have uninitialized bitmaps, I suppose I'll
> need to add a check to reconstruct the used blocks from the group
> descriptor table pointers.
>
> > Can you send me a compressed raw e2image of the file system so I can
> > take a look?
>
> Here it is.
Ah, so it's pretty self-explanatory. From the dumpe2fs of the image:
Group 25: (Blocks 819200-851967) csum 0x45a8 [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
^^^^^^^^^^^^^
Backup superblock at 819200, Group descriptors at 819201-819201
^^^^^^ ^^^^^^^^^^^^^
Reserved GDT blocks at 819202-819584
^^^^^^^^^^^^^
Block bitmap at 524297 (bg #16 + 9)
Inode bitmap at 524313 (bg #16 + 25)
Inode table at 528928-529439 (bg #16 + 4640)
32383 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
Free blocks: 819585-851967
Free inodes: 204801-212992
One of the things which we didn't do as part of flex_bg was to change
the location of the superblocks that had backup superblock and block
group descriptor blocks (which perhaps we should have done, but oh,
well). There is the sparse_super2 feature which would allow us to
reduce the number of backup superblocks down to two, one, or zero, but
that would require people using newer versions of e2fsprogs, so it's
not something we've enabled yet for wider use (although it is
something I've been using at $WORK).
- Ted
next prev parent reply other threads:[~2015-05-21 23:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 1:10 Unused block group, but all blocks not free? Phillip Susi
2015-05-20 15:10 ` Theodore Ts'o
2015-05-20 15:15 ` Phil Susi
2015-05-20 16:31 ` Theodore Ts'o
[not found] ` <555D0541.1000804@ubuntu.com>
2015-05-21 23:59 ` Theodore Ts'o [this message]
2015-05-22 0:08 ` Phillip Susi
2015-05-22 2:28 ` Theodore Ts'o
2015-05-22 12:37 ` Phil Susi
2015-05-23 3:05 ` Theodore Ts'o
2015-05-23 15:39 ` Phillip Susi
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=20150521235940.GB2750@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=psusi@ubuntu.com \
/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;
as well as URLs for NNTP newsgroup(s).