ext4: a tool to modify the inode count

ext4: a tool to modify the inode count

[Daniel Mazon]

Hello,

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.

Regards,
Daniel

Re: ext4: a tool to modify the inode count

[Andreas Dilger]

On Dec 17, 2025, at 11:04, Daniel Mazon <daniel.mazon@proton.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

Re: ext4: a tool to modify the inode count

[Daniel Mazon]

On Thursday, December 18th, 2025 at 09:09, Andreas Dilger <adilger@dilger.ca> wrote:

>
>
> On Dec 17, 2025, at 11:04, Daniel Mazon daniel.mazon@proton.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.
>

Hi Andreas,

Thanks for your reply.
I agree, this tool would be much more useful if it were integrated
in the e2fsprogs suite. I can spend some time to prepare a patch
if I get the pertinent ack.
IMHO, maybe the best approach would be to keep it in its own binary,
and compile with the object files containing the functions from resize2fs
which are used to also modify the inode count. This shall benefit from
reusing code, and not overload resize2fs with functionality (which
already does resizing and switching between 32/64 bits). But I will let
the experts decide on what is the best course of action.

Regards,
Daniel

Re: ext4: a tool to modify the inode count

[Theodore Tso]

On Mon, Dec 22, 2025 at 11:15:20PM +0000, Daniel Mazon wrote:
> IMHO, maybe the best approach would be to keep it in its own binary,
> and compile with the object files containing the functions from resize2fs
> which are used to also modify the inode count. This shall benefit from
> reusing code, and not overload resize2fs with functionality (which
> already does resizing and switching between 32/64 bits). But I will let
> the experts decide on what is the best course of action.

The reason why it's better to add that functionality to resize2fs is
that it's clear that you were doing a lot of code reuse by cut and
paste.  This is an anti-pattern, because when a bug is fixed in one
variant of the copied code, it sticks around in the other variant.
It's even worse when this copy-pasta is in security critical code,
because then when you fix the security bug in one copy of the code,
then the attacker might immediately check to see if you forgot it in
the other copy or worse, the several dozen other copies.  Hence the
meme[1], which warns against the spaghetti code that can result from
the really nasty practice of copy-pasta.     :-)

[1] https://tenor.com/view/copy-pasta-copy-fake-plagiarism-nft-gif-5062305734325825604

Yes, it might mean that we might need to refactor some of the
functions that you copied --- and then made changes --- but the
resulting functions will hopefully be more useful in other contexts or
for other use cases.  So it might be more work, yes.  But hopefully
the code will be higher quality.  (And part of the code review process
will be us trying to help you make the code be high quality before we
accept the patch, because what's critically important is the future
code maintainability of the code base.)

As a suggestion, perhaps "resize -i NNN" would resize the inode table
to have NNN inodes.  And perhaps "resize2fs -i +NNN" or "resize2fs -i
-NNN" would increase or decrease the inode table by NNN inodes.  (And
obviously we might need to round the number of inodes since the number
of inodes must be a multiple of 8, and should be a multiple of the
inodes per block.)

Cheers,

						- Ted