From: "Theodore Tso" <tytso@mit.edu>
To: Daniel Mazon <daniel.mazon@proton.me>
Cc: Andreas Dilger <adilger@dilger.ca>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: ext4: a tool to modify the inode count
Date: Mon, 22 Dec 2025 23:45:19 -0500 [thread overview]
Message-ID: <20251223044519.GF42033@macsyma.lan> (raw)
In-Reply-To: <woSqjqMgjW_pNb2fMhKZ20_RP4BrbYKrX6NHMhGu-n3Mt0VVdP0UiEEopdqeo63OehhHmTs2zJoF8UVU96_IaPiQRvrNyyo-FMCuoPAtKXQ=@proton.me>
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
prev parent reply other threads:[~2025-12-23 4:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-17 18:04 ext4: a tool to modify the inode count Daniel Mazon
2025-12-18 8:05 ` Andreas Dilger
2025-12-22 23:15 ` Daniel Mazon
2025-12-23 4:45 ` Theodore Tso [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251223044519.GF42033@macsyma.lan \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=daniel.mazon@proton.me \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.