Message-Id: <EB431D42-1CDA-4522-B365-8411801B684E@dilger.ca>
Date: Thu, 18 Dec 2025 01:05:50 -0700
From: Andreas Dilger <adilger@...ger.ca>
To: Daniel Mazon <daniel.mazon@...ton.me>
Cc: "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: ext4: a tool to modify the inode count

On Dec 17, 2025, at 11:04, Daniel Mazon <daniel.mazon@...ton.me> wrote:
> 
> I wrote a small tool to modify the inode count of an existing ext4 
> filesystem. It is largely based on the resize2fs tool from e2fsprogs. 
> Previously, the inode count was selected at filesystem creation and 
> could not be modified afterwards.
> 
> It provides a way to increase or reduce the inode count. I developed
> it because I had a 3.5 TiB ext4 partition created with a default
> 16384 bytes-per-inode ratio. This created over 200 million inodes,
> allocating over 50GiB to inode tables. However, I was using less than
> 0.1% of inodes, so I wanted to reallocate those unused GiB from inode
> tables to free space.
> 
> To test the program, I created testcases trying to cover all possible 
> ext4 options that could be impacted by a change on the inode count.
> After some time, I think it works well: no fsck errors after the
> change, and all data is still there. Please bear in mind that this
> has only been tested by one person.
> 
> I think this tool could be useful to someone else, as it adds
> flexibility on a parameter which was previouly unmodifiable. The code 
> can be found here: https://github.com/danim7/inode_count_modifier
> 
> Please don't hesitate to let me know if you give it a try. I hope this mailing list is the right place to communicate this, if not,
> please excuse me for the noise.

Hi Daniel,
thank you for your contribution.  Changing the inode count of an
existing filesystem independently of the block count is definitely
something that I've wanted to do at various times in the past,
and I'm sure lots of other ext4 users have wanted to do the same.


IMHO, your development efforts would be far more utilized if this
functionality was included directly into the resize2fs utility
(which your README.md mentions was the foundation for your code).

This will not only ensure that this capability continues to be
maintained as e2fsprogs is updated (e.g. if new features are added
to ext4 and/or e2fsprogs), but it also allows a *much* larger number
of users to have access to it when they need it.  Otherwise, it
seems likely that most users will not know "inode_count_modifier"
exists, and they will not be able to change the inode count.
Even worse, someone else might spend a lot of time to re-implement
this due to a similar requirement as yours.

It makes sense to get an Ack from Ted before spending time to do
that work, but I think it would be best for all ext4 users... and
you'd have your code installed on millions of computers worldwide.



On a related note, I've wondered if it makes sense to allow some
semi-dynamic online inode bitmap/itable changes within ext4?  In the
old days, the inode bitmaps were closely tied to the block groups.
With flex_bg and sparse_super2, "mke2fs -E packed_meta_blocks"
available in new e2fsprogs/ext4 there is little correlation between
the location of the inode bitmap and the blocks in the inode table.
This means it would be possible to allocate inode tables anywhere
in the filesystem as needed.

A new "EXT4_BG_NOINODE 0x0100" flag would be needed to mark a block
group without any inode table/bitmap (to reduce the number of inodes
vs. blocks), and similarly a "EXT4_BG_NOBLOCK 0x0200" flag to mark a
"blockless block group" that only has an inode bitmap/table (to add
inodes to a filesystem without increasing the size).

The ext4/e2fsprogs code would need to store the number of group descriptor entries independently of the total block count to
add "blockless block groups", but only the flag would be needed for
"inodeless block groups".

Unlike your "inode_count_modifier" (that moves blocks and renumbers
inodes), it would be possible (with ext4/e2fsprogs changes) to add
add new/empty inode bitmap and itable blocks online to an existing
filesystem (which must have some significant number of free blocks
for this to be worthwhile to do).

It is _likely_ also possible to online remove inode tables/bitmaps
from an existing filesystem by marking block groups with unused
inodes by setting the EXT4_BG_NOINODE flag and freeing the blocks
for the inode bitmap and itable.  This would only be worthwhile to
do if there are tons of unused inodes (as in your 0.1% use case),
so the chance of completely unused inode tables is very high.

Something like patch https://patchwork.ozlabs.org/project/linux-ext4/patch/9ba7e5de79b8b25e335026d57ec0640fc25e5ce0.1534905460.git.jaco@uls.co.za/ ("Add block_high_watermark sysfs tunable"), but as a
"inode_high_watermark sysfs tunable" could also be useful, to force
new inodes to be allocated below some cutoff.  That would avoid all
itable blocks at the end of the filesystem so they can be freed over
time (possibly after doing "cp -a FILE FILE.tmp && mv FILE.tmp FILE"
or similar to reallocate an in-use inode below the high watermark).

Cheers, Andreas

Powered by blists - more mailing lists