Re: [PATCH] Fix default orphan file size calculations

["Theodore Tso" <tytso@mit.edu>]

On Thu, Mar 12, 2026 at 12:27:07AM +0800, Baokun Li wrote:
> 
> In fact, the patch that introduced it was not the latest version —
> there was a later v3 that is consistent with the upstream kernel:

Hmm, I wonder why b4 didn't pick up the newer version of the patch.
Maybe I screwed up and missed the -c option to "b4 am -c".

The main difference between my proposed fix and your v3 patch is that
if the user doesn't specify an explicit orphan file size, with the v3
patch, it might max out to 8MB when the block size is 64k.  With my
fix, it will max out to 2MB in those situations.  The user can
explicitly specify a orphan file size as 8MB, but it makes the default
to be 2MB.

In retrospect, I think we went wrong when we capped the orphan file in
terms of bytes instead of blocks in the kernel.  When the block size
is 64k, 8MB is only 32 blocks.  When the block size is 4k, the orphan
file size can be up to 512 blocks.  And the scalability is really a
function of the number of blocks, not the number of bytes, since with
the orphan file, we use a hash that maps the cpu number to a logical
block number in orphan size.

Now, most of the time, I suspect 32 blocks is plenty most of the time,
since it's unlikely we'll have that many running processes trying to
truncate files or something else that requires adding the inode to the
oprhan file.

So I thought about just using a default orphan inode size of 32 file
system blocks.  I also thought about changing the kernel to allow size
of the orphan file to be say, up to 256 blocks.  And also maybe
allowing mke2fs and tune2fs to accept an extended options
orphan_file_blocks which takes an argument denominated in blocks.

Ultimately, though, *most* of the time, consuming 512MB on the orphan
file inode if the file system is say, 2TB.  So I decided it wasn't
worth the effort to change how things worked.  But if we were starting
from scratch, I think we would have been better of doing things in
terms of blocks, instead of bytes.

But maybe we should go and make that change.  What do folks think?

    	     	       	   	     	      - Ted