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

[Chuck Lever <chuck.lever@oracle.com>]

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.


-- 
Chuck Lever