From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <cel@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org
Cc: Chuck Lever <chuck.lever@oracle.com>,
Volker Lendecke <Volker.Lendecke@sernet.de>
Subject: Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx
Date: Fri, 26 Sep 2025 06:00:32 -0400 [thread overview]
Message-ID: <ad767899918d26817e44f1af213a8dfdce26508a.camel@kernel.org> (raw)
In-Reply-To: <20250925151140.57548-1-cel@kernel.org>
On Thu, 2025-09-25 at 11:11 -0400, Chuck Lever 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 */
>
>
Do you intend to expose this new attribute to userland? If not, then it
should probably snuggle up next to STATX_CHANGE_COOKIE. If so, then you
need to claim a field for it in struct statx, and populate it.
I'll also note that you're not using a lot of the bits in this field,
and struct statx has a 16-bit spare field next to stx_mode. You may
want to rework this to use a 16 bit field and expose it to userland
there.
>
> #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,
> +};
These all need _very_ clear definitions, especially if you're exposing
this to userland. The devil is in the details when it comes to
casefolding and there is not a lot of consistency across filesystems.
The callers need to know what they can expect when they see that these
bits are set.
> +#define STATX_CASE_FOLDING_TYPE 0x000000ff
> +
> #endif /* _UAPI_LINUX_STAT_H */
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2025-09-26 10:00 UTC|newest]
Thread overview: 20+ 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
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-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 [this message]
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=ad767899918d26817e44f1af213a8dfdce26508a.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=Volker.Lendecke@sernet.de \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).