I find the minimal size for the new resize2fs is lifted comparing to the old version.

log of old version - e2fsprogs-1.46.2-2.el9.x86_64
```
# losetup -f --show 1G.img
# mkfs.ext4 /dev/loop0 256M
# resize2fs /dev/loop0 16M
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/loop0 to 16384 (1k) blocks.
The filesystem on /dev/loop0 is now 16384 (1k) blocks long.
# e2fsck /dev/loop0
e2fsck 1.46.2 (28-Feb-2021)
/dev/loop0: clean, 11/4096 files, 9239/16384 blocks
```

log of new version - e2fsprogs-1.46.5-1.el9.x86_64
```
# losetup -f --show 1G.img
# mkfs.ext4 /dev/loop0 256M
# resize2fs /dev/loop0 26M

resize2fs 1.46.5 (30-Dec-2021)
resize2fs: New size smaller than minimum (27049)
```

Shrinking from 256M to 16M is fine in the old version, while the minimal size is as large as ~27M in the new version. @lczerner Is it a problem or expected?

(In reply to Boyang Xue from comment #2)
> I find the minimal size for the new resize2fs is lifted comparing to the old
> version.
> 
> log of old version - e2fsprogs-1.46.2-2.el9.x86_64
> ```
> # losetup -f --show 1G.img
> # mkfs.ext4 /dev/loop0 256M
> # resize2fs /dev/loop0 16M
> resize2fs 1.46.2 (28-Feb-2021)
> Resizing the filesystem on /dev/loop0 to 16384 (1k) blocks.
> The filesystem on /dev/loop0 is now 16384 (1k) blocks long.
> # e2fsck /dev/loop0
> e2fsck 1.46.2 (28-Feb-2021)
> /dev/loop0: clean, 11/4096 files, 9239/16384 blocks
> ```
> 
> log of new version - e2fsprogs-1.46.5-1.el9.x86_64
> ```
> # losetup -f --show 1G.img
> # mkfs.ext4 /dev/loop0 256M
> # resize2fs /dev/loop0 26M
> 
> resize2fs 1.46.5 (30-Dec-2021)
> resize2fs: New size smaller than minimum (27049)
> ```
> 
> Shrinking from 256M to 16M is fine in the old version, while the minimal
> size is as large as ~27M in the new version. @lczerner Is it a
> problem or expected?

Nice catch, good job. So this is because the rebase also changed the mke2fs.conf in that we no longer want to use 128 bytes inodes by default. It is considered deprecated and instead we're always defaulting to 256 bytes inodes. This is because 128 byte inodes can't handle dates past year 2038.

Previously, and this is true for the version 1.46.2-2 as well, we have used 256 bytes inodes by default except in the usage types small and floppy; that is file systems smaller than 512M and 3M respectively. This update changes that in RHEL9 and we're using 256 bytes inodes even with those smaller file systems. Since the inode tables are now larger this will have an effect on the minimum resize size. I think this really is marginal and overall the change is a benefit. Moreover given that this is for RHEL9.0 I think we can, and should, make this change to be on par with upstream since the beginning.

You can test it by checking the inode size on the file system itself (tune2fs -l) when using different versions as well as specifying inode size (-I) manually.

To sum it up, it is expected behavior.

Thanks!
-Lukas

(In reply to Lukáš Czerner from comment #3)
> (In reply to Boyang Xue from comment #2)
> > I find the minimal size for the new resize2fs is lifted comparing to the old
> > version.
> > 
> > log of old version - e2fsprogs-1.46.2-2.el9.x86_64
> > ```
> > # losetup -f --show 1G.img
> > # mkfs.ext4 /dev/loop0 256M
> > # resize2fs /dev/loop0 16M
> > resize2fs 1.46.2 (28-Feb-2021)
> > Resizing the filesystem on /dev/loop0 to 16384 (1k) blocks.
> > The filesystem on /dev/loop0 is now 16384 (1k) blocks long.
> > # e2fsck /dev/loop0
> > e2fsck 1.46.2 (28-Feb-2021)
> > /dev/loop0: clean, 11/4096 files, 9239/16384 blocks
> > ```
> > 
> > log of new version - e2fsprogs-1.46.5-1.el9.x86_64
> > ```
> > # losetup -f --show 1G.img
> > # mkfs.ext4 /dev/loop0 256M
> > # resize2fs /dev/loop0 26M
> > 
> > resize2fs 1.46.5 (30-Dec-2021)
> > resize2fs: New size smaller than minimum (27049)
> > ```
> > 
> > Shrinking from 256M to 16M is fine in the old version, while the minimal
> > size is as large as ~27M in the new version. @lczerner Is it a
> > problem or expected?
> 
> Nice catch, good job. So this is because the rebase also changed the
> mke2fs.conf in that we no longer want to use 128 bytes inodes by default. It
> is considered deprecated and instead we're always defaulting to 256 bytes
> inodes. This is because 128 byte inodes can't handle dates past year 2038.
> 
> Previously, and this is true for the version 1.46.2-2 as well, we have used
> 256 bytes inodes by default except in the usage types small and floppy; that
> is file systems smaller than 512M and 3M respectively. This update changes
> that in RHEL9 and we're using 256 bytes inodes even with those smaller file
> systems. Since the inode tables are now larger this will have an effect on
> the minimum resize size. I think this really is marginal and overall the
> change is a benefit. Moreover given that this is for RHEL9.0 I think we can,
> and should, make this change to be on par with upstream since the beginning.
> 
> You can test it by checking the inode size on the file system itself
> (tune2fs -l) when using different versions as well as specifying inode size
> (-I) manually.
> 
> To sum it up, it is expected behavior.
> 
> Thanks!
> -Lukas

Good to know. Thanks for the information! I find the 128 byte inode_size to 256 byte inode_size conversion happened in upstream commit

a23b50cd mke2fs: warn about missing y2038 support when formatting fresh ext4 fs

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: e2fsprogs), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:4043