Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Amir Goldstein]

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
> +
>  #endif /* _UAPI_LINUX_STAT_H */
> --
> 2.51.0
>

CC unicode maintainer and SMB list.

Thanks,
Amir.

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Gabriel Krisman Bertazi]

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

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Chuck Lever]

On 10/3/25 11:24 AM, Gabriel Krisman Bertazi wrote:
> Amir Goldstein <amir73il@gmail.com> writes:
> 
>> On Thu, Sep 25, 2025 at 5:21 PM Chuck Lever <cel@kernel.org> wrote:

>>> 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.

For the purposes of indicating case sensitivity and preservation, the
NFS protocol does not currently care about unicode version.

But this is a very flexible proposal right now. Please recommend what
you'd like to see here. I hope I've given enough leeway that a unicode
version could be provided for other API consumers.

(As I mentioned to Jeff, there is no user space statx component in the
current proposal, but it should get one if it is agreed that's useful to
include).

-- 
Chuck Lever

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Steve French]

On Fri, Oct 3, 2025 at 10:52 AM Gabriel Krisman Bertazi
<gabriel@krisman.be> wrote:
>
> 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.



The (SMB2/SMB3/SMB3.1.1) protocol specification documentation refers
to https://www.unicode.org/versions/Unicode5.0.0/ and states
"Unless otherwise specified, all textual strings MUST be in Unicode
version 5.0 format, as specified in [UNICODE], using the 16-bit
Unicode Transformation Format (UTF-16) form of the encoding."

-- 
Thanks,

Steve

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Gabriel Krisman Bertazi]

Chuck Lever <cel@kernel.org> writes:

> On 10/3/25 11:24 AM, Gabriel Krisman Bertazi wrote:
>> Amir Goldstein <amir73il@gmail.com> writes:
>> 
>>> On Thu, Sep 25, 2025 at 5:21 PM Chuck Lever <cel@kernel.org> wrote:
>
>>>> 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.
>
> For the purposes of indicating case sensitivity and preservation, the
> NFS protocol does not currently care about unicode version.
>
> But this is a very flexible proposal right now. Please recommend what
> you'd like to see here. I hope I've given enough leeway that a unicode
> version could be provided for other API consumers.

But also, encoding version information is filesystem-wide, so it would
fit statfs.

For filesystems using fs/unicode/, we'd want to expose the unicode
version, from sb->s_encoding->version and the sb->s_encoding_flags.
The tuple (version,flags)  defines the casefolding behavior.

Currently, it is written to the kernel log at mount-time, but that is
easily lost/wrapped.

> (As I mentioned to Jeff, there is no user space statx component in the
> current proposal, but it should get one if it is agreed that's useful to
> include).

I believe it is useful to expose it to userspace, simply because it
modifies the behavior of the filesystem.  An application like Steam can
poke it to decide whether it needs to enable compatibility alternatives
to in-kernel case-folding, instead of assuming the encoding and testing
if "chattr +F" works.

It is not a critical feature, because mkfs for all case-insensitive
filesystems only ever supported one unicode version and strict mode is
rarely used. But if we ever update unicode or provide more flavors of
casefolding for compatibility with other filesystems, which was
requested in the past, userspace would need to have a way to retrieve
that information.

-- 
Gabriel Krisman Bertazi

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Chuck Lever]

On 10/3/25 4:43 PM, Gabriel Krisman Bertazi wrote:
> Chuck Lever <cel@kernel.org> writes:
> 
>> On 10/3/25 11:24 AM, Gabriel Krisman Bertazi wrote:

>>> 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.
>>
>> For the purposes of indicating case sensitivity and preservation, the
>> NFS protocol does not currently care about unicode version.
>>
>> But this is a very flexible proposal right now. Please recommend what
>> you'd like to see here. I hope I've given enough leeway that a unicode
>> version could be provided for other API consumers.
> 
> But also, encoding version information is filesystem-wide, so it would
> fit statfs.

ext4 appears to have the ability to set the case folding behavior
on each directory, that's why I started with statx.


-- 
Chuck Lever

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[ronnie sahlberg]

On Sat, 4 Oct 2025 at 07:05, Chuck Lever <cel@kernel.org> wrote:
>
> On 10/3/25 4:43 PM, Gabriel Krisman Bertazi wrote:
> > Chuck Lever <cel@kernel.org> writes:
> >
> >> On 10/3/25 11:24 AM, Gabriel Krisman Bertazi wrote:
>
> >>> 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.
> >>
> >> For the purposes of indicating case sensitivity and preservation, the
> >> NFS protocol does not currently care about unicode version.
> >>
> >> But this is a very flexible proposal right now. Please recommend what
> >> you'd like to see here. I hope I've given enough leeway that a unicode
> >> version could be provided for other API consumers.
> >
> > But also, encoding version information is filesystem-wide, so it would
> > fit statfs.
>
> ext4 appears to have the ability to set the case folding behavior
> on each directory, that's why I started with statx.

I think that is effectively also the case for cifs.
Perhaps not for normal directories but when following DFS links or reparse
points you can traverse between servers/shares that have different
case handling.
So I think statx would make sense here too.

>
>
> --
> Chuck Lever
>

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Gabriel Krisman Bertazi]

Chuck Lever <cel@kernel.org> writes:

> On 10/3/25 4:43 PM, Gabriel Krisman Bertazi wrote:
>> Chuck Lever <cel@kernel.org> writes:
>> 
>>> On 10/3/25 11:24 AM, Gabriel Krisman Bertazi wrote:
>
>>>> 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.
>>>
>>> For the purposes of indicating case sensitivity and preservation, the
>>> NFS protocol does not currently care about unicode version.
>>>
>>> But this is a very flexible proposal right now. Please recommend what
>>> you'd like to see here. I hope I've given enough leeway that a unicode
>>> version could be provided for other API consumers.
>> 
>> But also, encoding version information is filesystem-wide, so it would
>> fit statfs.
>
> ext4 appears to have the ability to set the case folding behavior
> on each directory, that's why I started with statx.

Yes. casefold is set per directory, but the unicode version and
casefolding semantics used by those casefolded directories are defined
for the entire filesystem.

-- 
Gabriel Krisman Bertazi

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Chuck Lever]

On 10/3/25 5:15 PM, Gabriel Krisman Bertazi wrote:
> Chuck Lever <cel@kernel.org> writes:
> 
>> On 10/3/25 4:43 PM, Gabriel Krisman Bertazi wrote:
>>> Chuck Lever <cel@kernel.org> writes:
>>>
>>>> On 10/3/25 11:24 AM, Gabriel Krisman Bertazi wrote:
>>
>>>>> 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.
>>>>
>>>> For the purposes of indicating case sensitivity and preservation, the
>>>> NFS protocol does not currently care about unicode version.
>>>>
>>>> But this is a very flexible proposal right now. Please recommend what
>>>> you'd like to see here. I hope I've given enough leeway that a unicode
>>>> version could be provided for other API consumers.
>>>
>>> But also, encoding version information is filesystem-wide, so it would
>>> fit statfs.
>>
>> ext4 appears to have the ability to set the case folding behavior
>> on each directory, that's why I started with statx.
> 
> Yes. casefold is set per directory, but the unicode version and
> casefolding semantics used by those casefolded directories are defined
> for the entire filesystem.
> 

Got it. That keeps the proposed statx changes simple. Let me look at how
extensible the statfs API is. Actually that falls a little outside of
the mission to support NFS's needs, so perhaps that should be a separate
effort? Let me know what you think.


-- 
Chuck Lever

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Christian Brauner]

On Fri, Oct 03, 2025 at 05:15:24PM -0400, Gabriel Krisman Bertazi wrote:
> Chuck Lever <cel@kernel.org> writes:
> 
> > On 10/3/25 4:43 PM, Gabriel Krisman Bertazi wrote:
> >> Chuck Lever <cel@kernel.org> writes:
> >> 
> >>> On 10/3/25 11:24 AM, Gabriel Krisman Bertazi wrote:
> >
> >>>> 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.
> >>>
> >>> For the purposes of indicating case sensitivity and preservation, the
> >>> NFS protocol does not currently care about unicode version.
> >>>
> >>> But this is a very flexible proposal right now. Please recommend what
> >>> you'd like to see here. I hope I've given enough leeway that a unicode
> >>> version could be provided for other API consumers.
> >> 
> >> But also, encoding version information is filesystem-wide, so it would
> >> fit statfs.
> >
> > ext4 appears to have the ability to set the case folding behavior
> > on each directory, that's why I started with statx.
> 
> Yes. casefold is set per directory, but the unicode version and
> casefolding semantics used by those casefolded directories are defined
> for the entire filesystem.

I'm not too fond of wasting statx() space for this. Couldn't this be
exposed via the new file_getattr() system call?:

/*
 * Variable size structure for file_[sg]et_attr().
 *
 * Note. This is alternative to the structure 'struct file_kattr'/'struct fsxattr'.
 * As this structure is passed to/from userspace with its size, this can
 * be versioned based on the size.
 */
struct file_attr {
        __u64 fa_xflags;        /* xflags field value (get/set) */
        __u32 fa_extsize;       /* extsize field value (get/set)*/
        __u32 fa_nextents;      /* nextents field value (get)   */
        __u32 fa_projid;        /* project identifier (get/set) */
        __u32 fa_cowextsize;    /* CoW extsize field value (get/set) */
};

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Gabriel Krisman Bertazi]

Christian Brauner <brauner@kernel.org> writes:

> On Fri, Oct 03, 2025 at 05:15:24PM -0400, Gabriel Krisman Bertazi wrote:
>> Chuck Lever <cel@kernel.org> writes:
>> 
>> > On 10/3/25 4:43 PM, Gabriel Krisman Bertazi wrote:
>> >> Chuck Lever <cel@kernel.org> writes:
>> >> 
>> >>> On 10/3/25 11:24 AM, Gabriel Krisman Bertazi wrote:
>> >
>> >>>> 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.
>> >>>
>> >>> For the purposes of indicating case sensitivity and preservation, the
>> >>> NFS protocol does not currently care about unicode version.
>> >>>
>> >>> But this is a very flexible proposal right now. Please recommend what
>> >>> you'd like to see here. I hope I've given enough leeway that a unicode
>> >>> version could be provided for other API consumers.
>> >> 
>> >> But also, encoding version information is filesystem-wide, so it would
>> >> fit statfs.
>> >
>> > ext4 appears to have the ability to set the case folding behavior
>> > on each directory, that's why I started with statx.
>> 
>> Yes. casefold is set per directory, but the unicode version and
>> casefolding semantics used by those casefolded directories are defined
>> for the entire filesystem.
>
> I'm not too fond of wasting statx() space for this. Couldn't this be
> exposed via the new file_getattr() system call?:

Do you mean exposing of unicode version and flags to userspace? If so,
yes, for sure, it can be fit in file_get_attr. It was never exposed
before, so there is no user expectation about it!

Thanks,

-- 
Gabriel Krisman Bertazi

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Christian Brauner]

On Tue, Oct 07, 2025 at 01:18:32PM -0400, Gabriel Krisman Bertazi wrote:
> Christian Brauner <brauner@kernel.org> writes:
> 
> > On Fri, Oct 03, 2025 at 05:15:24PM -0400, Gabriel Krisman Bertazi wrote:
> >> Chuck Lever <cel@kernel.org> writes:
> >> 
> >> > On 10/3/25 4:43 PM, Gabriel Krisman Bertazi wrote:
> >> >> Chuck Lever <cel@kernel.org> writes:
> >> >> 
> >> >>> On 10/3/25 11:24 AM, Gabriel Krisman Bertazi wrote:
> >> >
> >> >>>> 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.
> >> >>>
> >> >>> For the purposes of indicating case sensitivity and preservation, the
> >> >>> NFS protocol does not currently care about unicode version.
> >> >>>
> >> >>> But this is a very flexible proposal right now. Please recommend what
> >> >>> you'd like to see here. I hope I've given enough leeway that a unicode
> >> >>> version could be provided for other API consumers.
> >> >> 
> >> >> But also, encoding version information is filesystem-wide, so it would
> >> >> fit statfs.
> >> >
> >> > ext4 appears to have the ability to set the case folding behavior
> >> > on each directory, that's why I started with statx.
> >> 
> >> Yes. casefold is set per directory, but the unicode version and
> >> casefolding semantics used by those casefolded directories are defined
> >> for the entire filesystem.
> >
> > I'm not too fond of wasting statx() space for this. Couldn't this be
> > exposed via the new file_getattr() system call?:
> 
> Do you mean exposing of unicode version and flags to userspace? If so,
> yes, for sure, it can be fit in file_get_attr. It was never exposed
> before, so there is no user expectation about it!

Imho it would fit better there than statx(). If this becomes really
super common than we can also later decide to additional expose it via
statx() but for now I think it'd be better to move this into the new
file_attr()* apis.

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Chuck Lever]

On 10/10/25 7:11 AM, Christian Brauner wrote:
>>> I'm not too fond of wasting statx() space for this. Couldn't this be
>>> exposed via the new file_getattr() system call?:
>> Do you mean exposing of unicode version and flags to userspace? If so,
>> yes, for sure, it can be fit in file_get_attr. It was never exposed
>> before, so there is no user expectation about it!
> Imho it would fit better there than statx(). If this becomes really
> super common than we can also later decide to additional expose it via
> statx() but for now I think it'd be better to move this into the new
> file_attr()* apis.

Christian, I'm still not clear what you mean by "this". Do you mean only
the unicode version? Or do you mean both the unicode version *and* the
case sensitivity/preservation flags?


-- 
Chuck Lever

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Darrick J. Wong]

On Fri, Oct 10, 2025 at 01:11:32PM +0200, Christian Brauner wrote:
> On Tue, Oct 07, 2025 at 01:18:32PM -0400, Gabriel Krisman Bertazi wrote:
> > Christian Brauner <brauner@kernel.org> writes:
> > 
> > > On Fri, Oct 03, 2025 at 05:15:24PM -0400, Gabriel Krisman Bertazi wrote:
> > >> Chuck Lever <cel@kernel.org> writes:
> > >> 
> > >> > On 10/3/25 4:43 PM, Gabriel Krisman Bertazi wrote:
> > >> >> Chuck Lever <cel@kernel.org> writes:
> > >> >> 
> > >> >>> On 10/3/25 11:24 AM, Gabriel Krisman Bertazi wrote:
> > >> >
> > >> >>>> 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.
> > >> >>>
> > >> >>> For the purposes of indicating case sensitivity and preservation, the
> > >> >>> NFS protocol does not currently care about unicode version.
> > >> >>>
> > >> >>> But this is a very flexible proposal right now. Please recommend what
> > >> >>> you'd like to see here. I hope I've given enough leeway that a unicode
> > >> >>> version could be provided for other API consumers.
> > >> >> 
> > >> >> But also, encoding version information is filesystem-wide, so it would
> > >> >> fit statfs.
> > >> >
> > >> > ext4 appears to have the ability to set the case folding behavior
> > >> > on each directory, that's why I started with statx.
> > >> 
> > >> Yes. casefold is set per directory, but the unicode version and
> > >> casefolding semantics used by those casefolded directories are defined
> > >> for the entire filesystem.
> > >
> > > I'm not too fond of wasting statx() space for this. Couldn't this be
> > > exposed via the new file_getattr() system call?:
> > 
> > Do you mean exposing of unicode version and flags to userspace? If so,
> > yes, for sure, it can be fit in file_get_attr. It was never exposed
> > before, so there is no user expectation about it!
> 
> Imho it would fit better there than statx(). If this becomes really
> super common than we can also later decide to additional expose it via
> statx() but for now I think it'd be better to move this into the new
> file_attr()* apis.

n00b question here: Can you enable (or disable) casefolding and the
folding scheme used?  My guess is that one ought to be able to do that
either (a) on an empty directory or (b) by reindexing the entire
directory if the filesystem supports that kind of thing?  But hey, it's
not like xfs supports any of that. ;)

--D

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Gabriel Krisman Bertazi]

"Darrick J. Wong" <djwong@kernel.org> writes:

> n00b question here: Can you enable (or disable) casefolding and the
> folding scheme used?  My guess is that one ought to be able to do that
> either (a) on an empty directory or (b) by reindexing the entire
> directory if the filesystem supports that kind of thing?  But hey, it's
> not like xfs supports any of that. ;)

We only support enabling/disabling on an empty directory.

Disabling casefolding on an already populated directory would be easier
to do - just re-index, as you said.  But to enable it, you'd need to
handle cases where you have two different files that now have the "same"
name (differing only by case). Then, which one you'll get is quite
unpredictable (perhaps, the order the dirent appears on-disk, etc).

So we just don't allow it.

-- 
Gabriel Krisman Bertazi

Re: [RFC PATCH] fs: Plumb case sensitivity bits into statx

[Christian Brauner]

On Fri, Oct 10, 2025 at 08:43:33AM -0400, Chuck Lever wrote:
> On 10/10/25 7:11 AM, Christian Brauner wrote:
> >>> I'm not too fond of wasting statx() space for this. Couldn't this be
> >>> exposed via the new file_getattr() system call?:
> >> Do you mean exposing of unicode version and flags to userspace? If so,
> >> yes, for sure, it can be fit in file_get_attr. It was never exposed
> >> before, so there is no user expectation about it!
> > Imho it would fit better there than statx(). If this becomes really
> > super common than we can also later decide to additional expose it via
> > statx() but for now I think it'd be better to move this into the new
> > file_attr()* apis.
> 
> Christian, I'm still not clear what you mean by "this". Do you mean only
> the unicode version? Or do you mean both the unicode version *and* the
> case sensitivity/preservation flags?

Sorry, my thought had been both would fit into file_getattr() if that's
feasible.