On Wed, 10 Sept 2025 at 16:35, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > 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. > It is per-filesystem. Windows 10/11 NTFS has an optional per-directory, but that causes all kinds of trouble, and per-directory case-insensitivity might be depreciated soon again (ReFS chokes on it). My recommendation is to stick with the per-filesystem setting. Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
