From: Gabriel Krisman Bertazi <gabriel@krisman.be>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Chuck Lever <cel@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
Chuck Lever <chuck.lever@oracle.com>,
Jeff Layton <jlayton@kernel.org>,
Volker Lendecke <Volker.Lendecke@sernet.de>,
CIFS <linux-cifs@vger.kernel.org>
Subject: Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx
Date: Fri, 03 Oct 2025 11:24:32 -0400 [thread overview]
Message-ID: <87tt0gqa8f.fsf@mailhost.krisman.be> (raw)
In-Reply-To: <CAOQ4uxj-d87B+L+WgbFgmBQqdrYzrPStyfOKtVfcQ19bOEV6CQ@mail.gmail.com> (Amir Goldstein's message of "Thu, 25 Sep 2025 17:50:48 +0200")
Amir Goldstein <amir73il@gmail.com> writes:
> On Thu, Sep 25, 2025 at 5:21 PM Chuck Lever <cel@kernel.org> wrote:
>>
>> From: Chuck Lever <chuck.lever@oracle.com>
>>
>> Both the NFSv3 and NFSv4 protocols enable NFS clients to query NFS
>> servers about the case sensitivity and case preservation behaviors
>> of shared file systems. Today, the Linux NFSD implementation
>> unconditionally returns "the export is case sensitive and case
>> preserving".
>>
>> However, a few Linux in-tree file system types appear to have some
>> ability to handle case-folded filenames. Some of our users would
>> like to exploit that functionality from their non-POSIX NFS clients.
>>
>> Enable upper layers such as NFSD to retrieve case sensitivity
>> information from file systems by adding a statx API for this
>> purpose. Introduce a sample producer and a sample consumer for this
>> information.
>>
>> If this mechanism seems sensible, a future patch might add a similar
>> field to the user-space-visible statx structure. User-space file
>> servers already use a variety of APIs to acquire this information.
>>
>> Suggested-by: Jeff Layton <jlayton@kernel.org>
>> Cc: Volker Lendecke <Volker.Lendecke@sernet.de>
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>> fs/fat/file.c | 5 +++++
>> fs/nfsd/nfs3proc.c | 35 +++++++++++++++++++++++++++--------
>> include/linux/stat.h | 1 +
>> include/uapi/linux/stat.h | 15 +++++++++++++++
>> 4 files changed, 48 insertions(+), 8 deletions(-)
>>
>> I'm certain this RFC patch has a number of problems, but it should
>> serve as a discussion point.
>>
>>
>> diff --git a/fs/fat/file.c b/fs/fat/file.c
>> index 4fc49a614fb8..8572e36d8f27 100644
>> --- a/fs/fat/file.c
>> +++ b/fs/fat/file.c
>> @@ -413,6 +413,11 @@ int fat_getattr(struct mnt_idmap *idmap, const struct path *path,
>> stat->result_mask |= STATX_BTIME;
>> stat->btime = MSDOS_I(inode)->i_crtime;
>> }
>> + if (request_mask & STATX_CASE_INFO) {
>> + stat->result_mask |= STATX_CASE_INFO;
>> + /* STATX_CASE_PRESERVING is cleared */
>> + stat->case_info = statx_case_ascii;
>> + }
>>
>> return 0;
>> }
>> diff --git a/fs/nfsd/nfs3proc.c b/fs/nfsd/nfs3proc.c
>> index b6d03e1ef5f7..b319d1c4385c 100644
>> --- a/fs/nfsd/nfs3proc.c
>> +++ b/fs/nfsd/nfs3proc.c
>> @@ -697,6 +697,31 @@ nfsd3_proc_fsinfo(struct svc_rqst *rqstp)
>> return rpc_success;
>> }
>>
>> +static __be32
>> +nfsd3_proc_case(struct svc_fh *fhp, struct nfsd3_pathconfres *resp)
>> +{
>> + struct path p = {
>> + .mnt = fhp->fh_export->ex_path.mnt,
>> + .dentry = fhp->fh_dentry,
>> + };
>> + u32 request_mask = STATX_CASE_INFO;
>> + struct kstat stat;
>> + __be32 nfserr;
>> +
>> + nfserr = nfserrno(vfs_getattr(&p, &stat, request_mask,
>> + AT_STATX_SYNC_AS_STAT));
>> + if (nfserr != nfs_ok)
>> + return nfserr;
>> + if (!(stat.result_mask & STATX_CASE_INFO))
>> + return nfs_ok;
>> +
>> + resp->p_case_insensitive =
>> + stat.case_info & STATX_CASE_FOLDING_TYPE ? 0 : 1;
>> + resp->p_case_preserving =
>> + stat.case_info & STATX_CASE_PRESERVING ? 1 : 0;
>> + return nfs_ok;
>> +}
>> +
>> /*
>> * Get pathconf info for the specified file
>> */
>> @@ -722,17 +747,11 @@ nfsd3_proc_pathconf(struct svc_rqst *rqstp)
>> if (resp->status == nfs_ok) {
>> struct super_block *sb = argp->fh.fh_dentry->d_sb;
>>
>> - /* Note that we don't care for remote fs's here */
>> - switch (sb->s_magic) {
>> - case EXT2_SUPER_MAGIC:
>> + if (sb->s_magic == EXT2_SUPER_MAGIC) {
>> resp->p_link_max = EXT2_LINK_MAX;
>> resp->p_name_max = EXT2_NAME_LEN;
>> - break;
>> - case MSDOS_SUPER_MAGIC:
>> - resp->p_case_insensitive = 1;
>> - resp->p_case_preserving = 0;
>> - break;
>> }
>> + resp->status = nfsd3_proc_case(&argp->fh, resp);
>> }
>>
>> fh_put(&argp->fh);
>> diff --git a/include/linux/stat.h b/include/linux/stat.h
>> index e3d00e7bb26d..abb47cbb233a 100644
>> --- a/include/linux/stat.h
>> +++ b/include/linux/stat.h
>> @@ -59,6 +59,7 @@ struct kstat {
>> u32 atomic_write_unit_max;
>> u32 atomic_write_unit_max_opt;
>> u32 atomic_write_segments_max;
>> + u32 case_info;
>> };
>>
>> /* These definitions are internal to the kernel for now. Mainly used by nfsd. */
>> diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
>> index 1686861aae20..e929b30d64b6 100644
>> --- a/include/uapi/linux/stat.h
>> +++ b/include/uapi/linux/stat.h
>> @@ -219,6 +219,7 @@ struct statx {
>> #define STATX_SUBVOL 0x00008000U /* Want/got stx_subvol */
>> #define STATX_WRITE_ATOMIC 0x00010000U /* Want/got atomic_write_* fields */
>> #define STATX_DIO_READ_ALIGN 0x00020000U /* Want/got dio read alignment info */
>> +#define STATX_CASE_INFO 0x00040000U /* Want/got case folding info */
>>
>> #define STATX__RESERVED 0x80000000U /* Reserved for future struct statx expansion */
>>
>> @@ -257,4 +258,18 @@ struct statx {
>> #define STATX_ATTR_WRITE_ATOMIC 0x00400000 /* File supports atomic write operations */
>>
>>
>> +/*
>> + * File system support for case folding is available via a bitmap.
>> + */
>> +#define STATX_CASE_PRESERVING 0x80000000 /* File name case is preserved */
>> +
>> +/* Values stored in the low-order byte of .case_info */
>> +enum {
>> + statx_case_sensitive = 0,
>> + statx_case_ascii,
>> + statx_case_utf8,
>> + statx_case_utf16,
>> +};
>> +#define STATX_CASE_FOLDING_TYPE 0x000000ff
Does the protocol care about unicode version? For userspace, it would
be very relevant to expose it, as well as other details such as
decomposition type.
>> +
>> #endif /* _UAPI_LINUX_STAT_H */
>> --
>> 2.51.0
>>
>
> CC unicode maintainer and SMB list.
Thanks for the CC, Amir!
>
> Thanks,
> Amir.
--
Gabriel Krisman Bertazi
next prev parent reply other threads:[~2025-10-03 15:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-25 15:11 [RFC PATCH] fs: Plumb case sensitivity bits into statx Chuck Lever
2025-09-25 15:50 ` Amir Goldstein
2025-10-03 15:24 ` Gabriel Krisman Bertazi [this message]
2025-10-03 15:34 ` Chuck Lever
2025-10-03 20:43 ` Gabriel Krisman Bertazi
2025-10-03 21:05 ` Chuck Lever
2025-10-03 21:11 ` ronnie sahlberg
2025-10-03 21:15 ` Gabriel Krisman Bertazi
2025-10-04 17:27 ` Chuck Lever
2025-10-06 11:19 ` Christian Brauner
2025-10-07 17:18 ` Gabriel Krisman Bertazi
2025-10-10 11:11 ` Christian Brauner
2025-10-10 12:43 ` Chuck Lever
2025-10-21 11:54 ` Christian Brauner
2025-10-10 14:49 ` Darrick J. Wong
2025-10-10 19:06 ` Gabriel Krisman Bertazi
2025-10-03 17:19 ` Steve French
2025-09-26 4:20 ` Christoph Hellwig
2025-09-26 13:02 ` Chuck Lever
2025-09-26 10:00 ` Jeff Layton
2025-09-26 13:05 ` Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tt0gqa8f.fsf@mailhost.krisman.be \
--to=gabriel@krisman.be \
--cc=Volker.Lendecke@sernet.de \
--cc=amir73il@gmail.com \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.