On Mon, Mar 09, 2026 at 12:00:49AM +0200, Adrian Bunk wrote:
> Source: libblockdev
> Version: 3.4.0-1
>
> My gut feeling is that the comment
> "at least 90 % should be available, so it should be reported"
> in the libblockdev tests makes an assumption that might sometimes
> be marginally incorrect, but I do not know why the new e2fsprogs
> version makes a difference here.
The new e2fsprogs version uses a different way calculating the size of
the orphan inode. Older versions of mke2fs has a orphan inode with 33
blocks. (num_blocks / 4096 == 138240 / 4096 == 33). But in the newer
version of mke2fs, we're now using an orphan inode with 135 blocks
(num_blocks / fs->blocksize == 138240 / 1024 == 135). The intent of
the commit 6f03c698ef53 ("libext2fs: fix orphan file size > kernel
limit with large blocksize") was to fix issues when the blocksize is
64k. We assumed that nothing would change when the block size was 4k
--- but what we didn't consider what might happen when the block size
is 1k.
Having an orphan inode which is sized to 135k isn't really insane, but
it's just enough to push overhead over 10%. On the other hand, is it
likely that we need to scale a file system with 138240k (135
megabytes) scale to the point that over 128 CPU's simultaneously
trying to delete or truncate inodes? Probably not. Scaling to 32
CPU's is probably plenty.
Obviously, the user can override the orphan inode size; but given that
most users won't, the defaults are important. I'll have to take a
closer look at that, but I would request that libblockdev be a bit
more relaxed in its tests.
But there also seems to be something else weird going on with the ext2
and ext3 file systems:
> 2577s ======================================================================
> 2577s FAIL: test_ext2_get_info
> (fs_tests.ext_test.ExtGetInfo.test_ext2_get_info)
> 2577s Verify that it is possible to get info about an ext2 file system
> 2577s ----------------------------------------------------------------------
> ...
> 2577s AssertionError: 138133 not greater than 138240.0
> 2577s
> 2577s ======================================================================
> 2577s FAIL: test_ext3_get_info
> (fs_tests.ext_test.ExtGetInfo.test_ext3_get_info)
> 2577s Verify that it is possible to get info about an ext3 file system
> 2577s ----------------------------------------------------------------------
> ...
> 2577s AssertionError: 138133 not greater than 138240.0
So this makes no sense. There should be more free blocks for ext2
over ext3, since ext2 doesn't have a journal.
> 2577s ======================================================================
> 2577s FAIL: test_ext4_get_info
> (fs_tests.ext_test.ExtGetInfo.test_ext4_get_info)
> 2577s Verify that it is possible to get info about an ext4 file system
> 2577s ----------------------------------------------------------------------
> ...
> 2577s AssertionError: 138133 not greater than 138240.0
And there should be more free blocks for ext3 when compared to ext4,
because ext4 has the orphan inode, when ext3 doesn't.
So I *think* there is something going on which is weird with how the
Blockdev is setting up the fs_ext[234]_mkfs. It appears that for all
of these tests, it's creating an ext4 file system, which I don't think
is what the test is trying to get at.
- Ted
