linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Gabriel Krisman Bertazi <gabriel@krisman.be>
Cc: Chuck Lever <cel@kernel.org>, 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, 10 Oct 2025 13:11:32 +0200	[thread overview]
Message-ID: <20251010-rodeln-meilenstein-0ebf47663d35@brauner> (raw)
In-Reply-To: <87zfa2pr4n.fsf@mailhost.krisman.be>

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.

  reply	other threads:[~2025-10-10 11:11 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 [this message]
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=20251010-rodeln-meilenstein-0ebf47663d35@brauner \
    --to=brauner@kernel.org \
    --cc=Volker.Lendecke@sernet.de \
    --cc=amir73il@gmail.com \
    --cc=cel@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=gabriel@krisman.be \
    --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).