Message-ID: <woSqjqMgjW_pNb2fMhKZ20_RP4BrbYKrX6NHMhGu-n3Mt0VVdP0UiEEopdqeo63OehhHmTs2zJoF8UVU96_IaPiQRvrNyyo-FMCuoPAtKXQ=@proton.me>
Date: Mon, 22 Dec 2025 23:15:20 +0000
From: Daniel Mazon <daniel.mazon@...ton.me>
To: Andreas Dilger <adilger@...ger.ca>, "tytso@....edu" <tytso@....edu>
Cc: "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: ext4: a tool to modify the inode count

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

>
>
> 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.
>

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

Powered by blists - more mailing lists