Re: [PATCH v2 1/6] fs: Add case sensitivity info to file_kattr

From: Trond Myklebust

Date: Fri Dec 12 2025 - 17:49:51 EST


On Sat, 2025-12-13 at 06:23 +0900, Theodore Tso wrote:
> On Fri, Dec 12, 2025 at 10:08:18AM -0500, Chuck Lever wrote:
> > The unicode v. ascii case folding information was included just as
> > an example. I don't have any use case for that, and as I told Eric,
> > those specifics can be removed from the API.
> >
> > The case-insensitivity and case-preserving booleans can be consumed
> > immediately by NFSD. These two booleans have been part of the NFSv3
> > and NFSv4 protocols for decades, in order to support NFS clients on
> > non-POSIX systems.
>
> I was worried that some clients might be using this information so
> they could do informed caching --- i,e., if they have "makefile"
> cached locally because the user typed "more < makefile" into their
> Windows Command.exe window, and then later on some program tries to
> access "Makefile" the client OS might decide that they "know" that
> "makefile" and "Makefile" are the same file.  But if that's the case,
> then it needs to have more details about whether it's ASCII versus
> Unicode 1.0 vs Unicode 17.0 case folding that be in use, or there
> might be "interesting" corner cases.

The Linux NFSv4 client has no clue about how to fold cases so, as Chuck
indicated, it uses the case insensitivity flag only to know when to be
more aggressive about revalidating cached positive dentries and/or
evicting cached negative dentries after the directory contents are seen
to change.

As of now, I'm aware of no plans to try to implement anything like the
"informed caching" you describe above.

> Which is why I've gotten increasingly more sympathetic to Linus's
> position that case folding is Hot Trash.  If it weren't for the fact
> that I really wanted to get Android out of using wrapfs (which is an
> even greater trash fire), I'd be regretting the fact that I helped to
> add insensitive file name support to Linux...
>
> - Ted

--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@xxxxxxxxxx, trond.myklebust@xxxxxxxxxxxxxxx