linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2025-10-03 15:51 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 [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-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 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).