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

[Jeff Layton <jlayton@kernel.org>]

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?
-- 
Jeff Layton <jlayton@kernel.org>