From: David Howells <dhowells@redhat.com>
To: Christian Brauner <brauner@kernel.org>
Cc: dhowells@redhat.com, Jeff Layton <jlayton@kernel.org>,
viro@zeniv.linux.org.uk, linux-afs@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
ceph-devel@vger.kernel.org, Jeff Layton <jlayton@redhat.com>
Subject: Re: [PATCH 1/4] vfs: report change attribute in statx for IS_I_VERSION inodes
Date: Tue, 16 Aug 2022 14:55:41 +0100 [thread overview]
Message-ID: <4066396.1660658141@warthog.procyon.org.uk> (raw)
In-Reply-To: <20220816134419.xra4krb3jwlm4npk@wittgenstein>
Christian Brauner <brauner@kernel.org> wrote:
> > +#define STATX_CHANGE_ATTR 0x00002000U /* Want/got stx_change_attr */
>
> I'm a bit worried that STATX_CHANGE_ATTR isn't a good name for the flag
> and field. Or I fail to understand what exact information this will
> expose and how userspace will consume it.
> To me the naming gives the impression that some set of generic
> attributes have changed but given that statx is about querying file
> attributes this becomes confusing.
>
> Wouldn't it make more sense this time to expose it as what it is and
> call this STATX_INO_VERSION and __u64 stx_ino_version?
I'm not sure that STATX_INO_VERSION is better that might get confused with the
version number that's used to uniquify inode slots (ie. deal with inode number
reuse).
The problem is that we need fsinfo() or similar to qualify what this means.
On some filesystems, it's only changed when the data content changes, but on
others it may get changed when, say, xattrs get changed; further, on some
filesystems it might be monotonically incremented, but on others it's just
supposed to be different between two consecutive changes (nfs, IIRC).
David
next prev parent reply other threads:[~2022-08-16 13:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-16 13:27 [PATCH 0/4] vfs: expose the inode change attribute via statx Jeff Layton
2022-08-16 13:27 ` [PATCH 1/4] vfs: report change attribute in statx for IS_I_VERSION inodes Jeff Layton
2022-08-16 13:44 ` Christian Brauner
2022-08-16 13:52 ` Jeff Layton
2022-08-16 13:55 ` David Howells [this message]
2022-08-16 14:02 ` Jeff Layton
2022-08-16 15:15 ` David Howells
2022-08-16 15:32 ` Jeff Layton
2022-08-16 15:51 ` Darrick J. Wong
2022-08-16 16:05 ` Jeff Layton
2022-08-18 20:24 ` Jeff Layton
2022-08-16 13:27 ` [PATCH 2/4] nfs: report the change attribute if requested Jeff Layton
2022-08-16 13:27 ` [PATCH 3/4] afs: fill out change attribute in statx replies Jeff Layton
2022-08-16 13:27 ` [PATCH 4/4] ceph: fill in the change attribute in statx requests Jeff Layton
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=4066396.1660658141@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=jlayton@kernel.org \
--cc=jlayton@redhat.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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