Message-ID: <EAC144C5F16D12E1+20251211092106.38127aec@winn-pc>
Date: Thu, 11 Dec 2025 09:21:06 +0800
From: Winston Wen <wentao@...ontech.com>
To: "Theodore Tso" <tytso@....edu>
Cc: linux-ext4@...r.kernel.org
Subject: Re: Inquiry: Possible built-in support for longer filenames in ext4
 (beyond 256 bytes)

On Thu, 11 Dec 2025 08:24:59 +0900
"Theodore Tso" <tytso@....edu> wrote:

Hi Ted,

Thank you for your detailed and thoughtful response. Your insights are
greatly appreciated.

> On Wed, Dec 10, 2025 at 05:32:02PM +0800, Winston Wen wrote:
> > To better understand, I’ve reviewed the readdir/getdents man pages
> > and the glibc struct dirent definition. It appears that d_name is
> > implemented as a flexible array member rather than a fixed-size
> > array of 256 bytes.  
> 
> Intresting; the struture definition I quoted was from the readdir man
> page.

Indeed, the readdir.3 man page does show the definition you quoted. The
actual implementation in glibc headers and the readdir.2/getdents.2
system call interface uses a flexible array, as you noted.

> 
> I suspect there may be some number of random failures that might occur
> because of hidden dependencies on the historical / traditional value
> of NAME_MAX.  For example, it might be OK for glibc; but what about
> other C libraries that ship on Linux, such as musl, dietlibc, bionic,
> etc.?
> 

This is a valid concern. We have not tested with other C libraries such
as musl, dietlibc, or bionic. In our use case, primarily file migration
and document management operations, we have been using FUSE or wrapfs
to mount specific directories on demand, rather than entire home
directories. This has worked for our limited scope.

Your point also reminds me that seeking universal support may not be
the right path. NAME_MAX has been around for a long time, and many code
paths may depend on it in ways we haven’t encountered yet.

> > Going back to our original question: we were curious whether it
> > might be possible to support longer filenames natively within ext4
> > itself (rather than through FUSE), perhaps via on-disk format
> > extension or auxiliary storage like xattrs. If this is
> > architecturally feasible, we would be very interested in exploring
> > it further.  
> 
> Well, extended attributes won't work, because xattrs are associated
> with the inode, not the directory entry.  So you need to handle cases
> where the file has multiple hard links.  And if you are doing a lookup
> by long file name, there's a chicken and egg problem; you can't match
> against the full filename until you read the xattr, and you can't do
> that until you've lookup.
> 

Understood, that makes sense. Thank you for explaining the fundamental
limitation with xattrs.

> The only way to do this would be to make an incompatible change to the
> directory layout.  And doing this would require either refactoring and
> doing extensive rework of the code in fs/ext4/namei.c and
> fs/ext4/dir.c, to support both the the original v1 version of the
> directory layout, and the v2 version of the directory layout, as well
> as handling the v2 verison of the directory when it is encrypted.
> It's _doable_, but it's a huge amount of work.  So the question is
> whether it's worth it.  If this is some random class project where you
> don't care about bugs or reliability, that's one thing.  If this is
> something that need to be hardened for production usage, it's quite a
> lot more work.
> 

I completely agree. Changing the on‑disk format would indeed be a
massive undertaking and far beyond our current capacity. It would also
introduce stability and compatibility risks that we are not prepared to
take. Given that, we will likely not pursue this direction.

> Why are you interested in doing this?  Is there business justification
> such that your company would be willing invest a significant amount of
> effort?

This is actually an interesting point. Personally, I’ve never hit this
limit in my own Linux usage, 80 Chinese characters is far more than I
typically need. However, many of our customers work with official
documents (e.g., government or enterprise paperwork) where filenames
regularly exceed this limit. So the requirement comes from real‑world
business projects.

That said, because the need is mostly confined to document directories,
we can continue to use FUSE or wrapfs for targeted support, even though
it introduces some usability overhead. It’s a workable solution for our
specific scenario.

> 
> Cheers,
> 
> 						- Ted
> 

Thank you again for taking the time to explain the technical and
practical constraints. Your guidance has been very helpful.

-- 
Thanks,
Winston

Powered by blists - more mailing lists