[bug report] e2fsprogs 1.47.4: mke2fs creates oversized orphan file for 1k blocksize (breaks mount)

[bug report] e2fsprogs 1.47.4: mke2fs creates oversized orphan file for 1k blocksize (breaks mount)

[Yi Zhang]

Hi

I'm reporting a regression in e2fsprogs-1.47.4 where mke2fs creates an
orphan file[2] that exceeds the kernel's maximum allowed size for
filesystems with a 1KB block size[1]. This causes subsequent mount
operations to fail.

This issue is currently causing blktests loop/007 to fail on latest
Fedora. Downgrading to e2fsprogs 1.47.3 resolves the issue.
And revert [3] fixed this issue, here is the reproducer[4].

[1]
Kernel limit for 1KB blocks: 512 * 1024 = 512 KB
[2]
Orphan file created by e2fsprogs 1.47.4: 1024 KB (1 MB)
[3]
6f03c698 libext2fs: fix orphan file size > kernel limit with large blocksize
[4]
# dd if=/dev/zero of=test.img bs=1M count=1024
# mkfs.ext4 -b 1024 test.img  -F
mke2fs 1.47.4 (6-Mar-2025)
test.img contains a ext4 file system
        last mounted on Mon Mar 23 20:32:40 2026
Discarding device blocks: done
Creating filesystem with 1048576 1k blocks and 65536 inodes
Filesystem UUID: 16683060-ed47-46cc-a040-c5e049785831
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409, 663553,
        1024001

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
# mount test.img /mnt
mount: /mnt: fsconfig() failed: Structure needs cleaning.
       dmesg(1) may have more information after failed mount system call.

# dmesg
[ 5985.339637] loop0: detected capacity change from 0 to 2097152
[ 5985.347473] EXT4-fs (loop0): orphan file too big: 1048576
[ 5985.352939] EXT4-fs (loop0): mount failed


-- 
Best Regards,
  Yi Zhang

Re: [bug report] e2fsprogs 1.47.4: mke2fs creates oversized orphan file for 1k blocksize (breaks mount)

[Baokun Li]

Hi,

On 3/24/26 8:54 AM, Yi Zhang wrote:
> Hi
>
> I'm reporting a regression in e2fsprogs-1.47.4 where mke2fs creates an
> orphan file[2] that exceeds the kernel's maximum allowed size for
> filesystems with a 1KB block size[1]. This causes subsequent mount
> operations to fail.
>
> This issue is currently causing blktests loop/007 to fail on latest
> Fedora. Downgrading to e2fsprogs 1.47.3 resolves the issue.
> And revert [3] fixed this issue, here is the reproducer[4].
>
> [1]
> Kernel limit for 1KB blocks: 512 * 1024 = 512 KB
> [2]
> Orphan file created by e2fsprogs 1.47.4: 1024 KB (1 MB)
> [3]
> 6f03c698 libext2fs: fix orphan file size > kernel limit with large blocksize

Refer to the discussion in [a], you can revert [3] and apply [b] to fix
this issue.

[a]:
https://lore.kernel.org/linux-ext4/d4d64000-6b55-449e-83bb-be438aaa5146@linux.alibaba.com/
[b]:
https://lore.kernel.org/linux-ext4/20251120135514.3013973-1-libaokun@huaweicloud.com/


Cheers,
Baokun

> [4]
> # dd if=/dev/zero of=test.img bs=1M count=1024
> # mkfs.ext4 -b 1024 test.img  -F
> mke2fs 1.47.4 (6-Mar-2025)
> test.img contains a ext4 file system
>         last mounted on Mon Mar 23 20:32:40 2026
> Discarding device blocks: done
> Creating filesystem with 1048576 1k blocks and 65536 inodes
> Filesystem UUID: 16683060-ed47-46cc-a040-c5e049785831
> Superblock backups stored on blocks:
>         8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409, 663553,
>         1024001
>
> Allocating group tables: done
> Writing inode tables: done
> Creating journal (16384 blocks): done
> Writing superblocks and filesystem accounting information: done
> # mount test.img /mnt
> mount: /mnt: fsconfig() failed: Structure needs cleaning.
>        dmesg(1) may have more information after failed mount system call.
>
> # dmesg
> [ 5985.339637] loop0: detected capacity change from 0 to 2097152
> [ 5985.347473] EXT4-fs (loop0): orphan file too big: 1048576
> [ 5985.352939] EXT4-fs (loop0): mount failed
>
>

Re: [bug report] e2fsprogs 1.47.4: mke2fs creates oversized orphan file for 1k blocksize (breaks mount)

[Theodore Tso]

I will be releasing an updated e2fsprogs 1.47.5 in the next day or two
to address this issue.  Our apologies for the inconvenience.

   	   		    	      	  - Ted