Re: Inquiry: Possible built-in support for longer filenames in ext4 (beyond 256 bytes)

[Andi Kleen <ak@linux.intel.com>]

On Sat, Dec 13, 2025 at 08:35:37AM +0900, Theodore Tso wrote:
> On Fri, Dec 12, 2025 at 10:10:36AM -0800, Andi Kleen wrote:
> > 
> > Perhaps you could use xattrs on the directory inode to store the longer
> > names, or the overflow.
> > 
> > One problem is that they may need to be big, exceeding xattr
> > limits, but perhaps some total limit on the longer file names
> > would be acceptable.
> 
> With ext4, there is a limit of a single file system block for all
> extended attributes.  You can store the value of extended attribute in

With the bs>page size support this special use case could use larger 
blocks.

> an inode, in which case you only have the four byte inode number in
> the xattr block.  But still, if you assume 16 bytes of overhead for
> each xattr entry, plus the xattr header, there's only room for 9 400
> byte directory entries.

You would only need to store the overflow, and I assume most uses 
would be much shorter anyways. But yes it would add some limit
to the number of file names, but perhaps with a 64k and an average 
more toward 200 bytes it isn't that bad.

> 
> And you wouldn't want to have a lot of directory entries stored in
> xattrs anyway, since searching them would have to be a brute force,
> O(n) search.  You wouldn't be able to use a hash tree for fast
> lookups.

You could do the hash still on the original directory, and then
perhaps use 4 bytes of the original file name to point to an
xattr offset for the overflow. This would be incompatible of course,
but not too far from original ext4.

Perhaps it would also need something to have an efficient free list
in the xattr, or maybe that could be just done in memory.

-Andi