lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150520151007.GK2871@thunk.org>
Date:	Wed, 20 May 2015 11:10:07 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Phillip Susi <psusi@...ntu.com>
Cc:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Unused block group, but all blocks not free?

On Tue, May 19, 2015 at 09:10:12PM -0400, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> I broke out the old e2defrag for an experiment today ( wondering why
> resize2fs refuses to shrink a volume below half its size even though
> it is only 33% used; thought I would try packing all files as far to
> the left as possible and try again ) and it bailed out because the
> free block count listed in the superblock does not match what the
> block allocation bitmaps indicate.  It turns out this is due to some
> block groups that are unused, and thus have uninitialized allocation
> bitmaps, yet somehow claim to not have all of their blocks free.  The
> stats output from debugfs shows this:
> 
>  Group 25: block bitmap at 524297, inode bitmap at 524313, inode table
> at 528928
>            32383 free blocks, 8192 free inodes, 0 used directories,
> 8192 unused inodes
>            [Inode not init, Block not init, Checksum 0x45a8]
> 
> 
> How on earth can this be?  The block allocation bitmap is
> uninitialized, therefore all bits are assumed to be clear.  Yet the
> free blocks count is only 32383 instead of 32768.  How can a block
> group be totally unused, and yet not have all of its blocks free?

Have you checked to see if the metadata for other block groups are
taking up space in the block group.  This can happen when using the
flex_bg layout.  (And without flex_bg, then *all* block groups will
always have blocks in use, for their own metadata blocks.)

						- 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ