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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 19 May 2015 21:10:12 -0400
From:	Phillip Susi <>
To:	ext4 development <>
Subject: Unused block group, but all blocks not free?

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?

Version: GnuPG v1

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists