On 9/10/25 7:10 AM, Jeff Layton wrote: > On Tue, 2025-09-09 at 18:06 +0200, Cedric Blancher wrote: >> On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: >>> >>> On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote: >>>>> Date: Wed May 21 16:50:46 2008 +1000 >>>>> >>>>> dcache: Add case-insensitive support d_ci_add() routine >>>> >>>> My memory must be quite faulty then. I remember there being significant >>>> controversy at the Park City LSF around some patches adding support for >>>> case insensitivity. But so be it -- I must not have paid terribly close >>>> attention due to lack of oxygen. >>> >>> Well, that is when the ext4 CI code landed, which added the unicode >>> normalization, and with that another whole bunch of issues. >> >> Well, no one likes the Han unification, and the mess the Unicode >> consortium made from that, >> But the Chinese are working on a replacement standard for Unicode, so >> that will be a lot of FUN =:-) >> >>>>> That being said no one ever intended any of these to be exported over >>>>> NFS, and I also question the sanity of anyone wanting to use case >>>>> insensitive file systems over NFS. >>>> >>>> My sense is that case insensitivity for NFS exports is for Windows-based >>>> clients >>> >>> I still question the sanity of anyone using a Windows NFS client in >>> general, but even more so on a case insensitive file system :) >> >> Well, if you want one and the same homedir on both Linux and Windows, >> then you have the option between the SMB/CIFS and the Windows NFSv4.2 >> driver (I'm not counting the Windows NFSv3 driver due lack of ACL >> support). >> Both, as of September 2025, work fine for us for production usage. >> >>>> Does it, for example, make sense for NFSD to query the file system >>>> on its case sensitivity when it prepares an NFSv3 PATHCONF response? >>>> Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition >>>> of internationalized file names? >>> >>> Linus hates pathconf any anything like it with passion. Altough we >>> basically got it now with statx by tacking it onto a fast path >>> interface instead, which he now obviously also hates. But yes, nfsd >>> not beeing able to query lots of attributes, including actual important >>> ones is largely due to the lack of proper VFS interfaces. >> >> What does Linus recommend as an alternative to pathconf()? >> >> Also, AGAIN the question: >> Due lack of a VFS interface and the urgend use case of needing to >> export a case-insensitive filesystem via NFSv4.x, could we please get >> two /etc/exports options, one setting the case-insensitive boolean >> (true, false, get-default-from-fs) and one for case-preserving (true, >> false, get-default-from-fs)? >> >> So far LInux nfsd does the WRONG thing here, and exports even >> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1 >> server does it correctly. >> >> Ced > > I think you don't want an export option for this. > > It sounds like what we really need is a mechanism to determine whether > the inode the client is doing a GETATTR against lies on a case- > insensitive mount. > > Is there a way to detect that in the kernel? Agreed, I would prefer something automatic rather than an explicit export option. The best approach is to set this behavior on the underlying file system via its mount options or on-disk settings. That way, remote and local users see the exact same CS behavior. An export option would enable NFSD to lie about case sensitivity. Maybe that's what is needed? I don't really know. It seems like a potential interoperability disaster. Moreover, as we determined the last time this thread was active, ext4 has a per-directory case insensitivity setting. The NFS protocol's CS attribute is per file system. That's a giant mismatch in semantics, and I don't know what to do about that. An export option would basically override all of that -- as a hack -- but would get us moving forward. Again, perhaps there are some significant risks to this approach. -- Chuck Lever
