linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gabriel Krisman Bertazi <gabriel@krisman.be>
To: Chuck Lever <cel@kernel.org>
Cc: Amir Goldstein <amir73il@gmail.com>,
	 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 16:43:04 -0400	[thread overview]
Message-ID: <87plb3ra1z.fsf@mailhost.krisman.be> (raw)
In-Reply-To: <28ffeb31-beec-4c7a-ad41-696d0fd54afe@kernel.org> (Chuck Lever's message of "Fri, 3 Oct 2025 11:34:17 -0400")

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

  reply	other threads:[~2025-10-03 20:43 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 [this message]
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=87plb3ra1z.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).