Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

Cedric Blancher
2025-09-11T06:52:51Z

On Wed, 10 Sept 2025 at 16:35, Chuck Lever <chuck.lever@oracle.com> 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@infradead.org> 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@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur