Message-Id: <ed9d790a-fea8-4f3e-8118-d3a59d31107b@app.fastmail.com>
Date: Fri, 12 Dec 2025 10:08:18 -0500
From: "Chuck Lever" <cel@...nel.org>
To: "Theodore Tso" <tytso@....edu>
Cc: "Eric Biggers" <ebiggers@...nel.org>,
 "Alexander Viro" <viro@...iv.linux.org.uk>,
 "Christian Brauner" <brauner@...nel.org>, linux-fsdevel@...r.kernel.org,
 linux-ext4@...r.kernel.org, linux-nfs@...r.kernel.org,
 linux-kernel@...r.kernel.org, hirofumi@...l.parknet.co.jp,
 almaz.alexandrovich@...agon-software.com, adilger.kernel@...ger.ca,
 Volker.Lendecke@...net.de, "Chuck Lever" <chuck.lever@...cle.com>
Subject: Re: [PATCH v2 1/6] fs: Add case sensitivity info to file_kattr



On Thu, Dec 11, 2025, at 9:18 PM, Theodore Tso wrote:
> On Thu, Dec 11, 2025 at 08:16:45PM -0500, Chuck Lever wrote:
>> 
>> > I see you're proposing that ext4, fat, and ntfs3 all set
>> > FILEATTR_CASEFOLD_UNICODE, at least in some cases.
>> >
>> > That seems odd, since they don't do the matching the same way.
>> 
>> The purpose of this series is to design the VFS infrastructure. Exactly what
>> it reports is up to folks who actually understand i18n.
>
> Do we know who would be receiving this information and what their needs 
> might be?

The unicode v. ascii case folding information was included just as
an example. I don't have any use case for that, and as I told Eric,
those specifics can be removed from the API.

The case-insensitivity and case-preserving booleans can be consumed
immediately by NFSD. These two booleans have been part of the NFSv3
and NFSv4 protocols for decades, in order to support NFS clients on
non-POSIX systems.

I'm told that Samba has to detect and expose file system case folding
behavior to its clients as well. Supporting Samba and other user
space file servers is why this series exposes case folding information
via a local user-space API. I don't know of any other category of
user-space application that requires access to case folding info.


The Linux NFS community has a growing interest in supporting NFS
clients on Windows and MacOS platforms, where file name behavior does
not align with traditional POSIX semantics.

One example of a Windows-based NFS client is [1]. This client
implementation explicitly requires servers to report
FATTR4_WORD0_CASE_INSENSITIVE = TRUE for proper operation, a hard
requirement for Windows client interoperability because Windows
applications expect case-insensitive behavior. When an NFS client
knows the server is case-insensitive, it can avoid issuing multiple
LOOKUP/READDIR requests to search for case variants, and applications
like Win32 programs work correctly without manual workarounds or
code changes.

Even the Linux client can take advantage of this information. Trond
merged patches 4 years ago [2] that introduce support for case
insensitivity, in support of the Hammerspace NFS server. In
particular, when a client detects a case-insensitive NFS share,
negative dentry caching must be disabled (a lookup for "FILE.TXT"
failing shouldn't cache a negative entry when "file.txt" exists)
and directory change invalidation must clear all cached case-folded
file name variants.

Hammerspace servers and several other NFS server implementations
operate in multi-protocol environments, where a single file service
instance caters to both NFS and SMB clients. In those cases, things
work more smoothly for everyone when the NFS client can see and adapt
to the case folding behavior that SMB users rely on and expect. NFSD
needs to support the case-insensitivity and case-preserving booleans
properly in order to participate as a first-class citizen in such
environments.

As a side note: I assumed these details were already well-known in
this community; otherwise I would have included it in the series
cover letter. I can include it when posting subsequent revisions.

-- 
Chuck Lever

[1] https://github.com/kofemann/ms-nfs41-client

[2] https://patchwork.kernel.org/project/linux-nfs/cover/20211217203658.439352-1-trondmy@kernel.org/

Powered by blists - more mailing lists