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@xxxxxxxxxx>
