Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Jeff Layton <jlayton@kernel.org>]

On Sat, 2025-06-07 at 22:39 +0000, Theodore Ts'o wrote:
> On Sat, Jun 07, 2025 at 02:30:37PM -0400, Chuck Lever wrote:
> > 
> > My impression is that real case-insensitivity has been added to the
> > dentry cache in support of FAT on Android devices (or something like
> > that). That clears the path a bit for NFSD, but it needs to be
> > researched to see if that new support is adequate for NFS to use.
> 
> Case insensitivty was added in Linux in 2019, with the primary coding
> work being done by Gabriel Krisman Bertazi of Collabora, and design
> work being done being done by Gabriel, Michael Halcrow, and myself.
> (Michael Halcrow in particular was responsible for devising how to
> make case-insensitivity work with filename encryption and indexed
> directories.)
> 
> The initial file systems that had case-insensitivty implemented was
> ext4 and f2fs.  The initial use cases was Android devices (which had
> used this horible wrapfs stacking file system thing which was trivial
> to deadlock under stress, and its original reason for existing was
> bug-for-bug compatibility with FAT), and for Steam so that Windows
> games could have their expected case insensitivity.  (Collabora's work
> was underwritten by Steam.)
> 
> There is an interesting write-up about NFS and case-insensitivity in a
> relatively recent Internet-Draft[1], dated 2025-May-16.  In this I-D,
> it points out that one of the primary concerns is that if the client
> caches negative lookups under one case (say, MaDNeSS), and then the
> file is created using a different case (say "madness"), then the
> negative dentry cache indicating that MaDNeSS does not exist needs to
> be removed when "madness" is created.  I'm not sure how Linux's NFS
> client handles negative dentries, since even without
> case-insensitivity, a file name that previously didn't exist could
> have subsequently been created by another client on a different host.
> So does Linux's NFS client simply does not use negative dentries, or
> does it have some kind of cache invalidation scheme when the directory
> has a new mtime, or some such?
> 

It's a little more complicated than that, but that's basically right:

When the attrs on the parent directory indicate that there has been a
change to it since a dentry was last revalidated, the client will
return <=0 to d_revalidate attempts on the dentry. That will make the
VFS re-drive a lookup instead of trusting the cache.


> [1] https://www.ietf.org/id/draft-ietf-nfsv4-internationalization-12.html#name-handling-of-string-equivale
> 
> Anyway, case sensitivity is one of those "interesting" problems which
> has caused many headaches, including a potential security issue, and a
> botched attempt to fix that security issue interacting poorly with
> some of the more subtle design requirements so that file systems can
> use tree-indexed directory lookups, even with case-insensitivty file
> names and encrypted directory entries.  So in general, unless you have
> strong financial backing where someone is willing to pay $$$ to
> address a business-critical use case, my personal advice is to stay
> far, far, away.  And I say this as a someone (with apologies to Linus)
> who was partially responsible for Linux having case insensitivty
> lookups in the first place.  :-)

-- 
Jeff Layton <jlayton@kernel.org>