On 9/10/25 10:30 AM, Jeff Layton wrote: > On Wed, 2025-09-10 at 10:14 -0400, Chuck Lever wrote: >> 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. >> > > There is also the issue that exports can span filesystems. If you have > one fs that is case-sensitive mounted on another that is not, and then > you export the whole mess, the results sound sketchy. > >> 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. >> > > The spec is written such that case-sensitivity applies to the whole fs, > but in practical terms, would there be any harm in allowing this to be > set more granularly? > > Existing servers would still work fine in that case, and I don't think > it would be an issue for the Linux client at least. Yep, the issue is how existing NFS client implementations treat fattr4_case_insensitive and fattr4_case_preserving. Research is needed. -- Chuck Lever
