From: Jeff Layton <jlayton@kernel.org>
To: tytso@mit.edu, adilger.kernel@dilger.ca, djwong@kernel.org,
david@fromorbit.com, trondmy@hammerspace.com, neilb@suse.de,
viro@zeniv.linux.org.uk, zohar@linux.ibm.com, xiubli@redhat.com,
chuck.lever@oracle.com, lczerner@redhat.com, jack@suse.cz,
brauner@kernel.org
Cc: linux-api@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-ceph@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org,
Colin Walters <walters@verbum.org>
Subject: [PATCH v3 1/7] iversion: update comments with info about atime updates
Date: Fri, 26 Aug 2022 17:46:57 -0400 [thread overview]
Message-ID: <20220826214703.134870-2-jlayton@kernel.org> (raw)
In-Reply-To: <20220826214703.134870-1-jlayton@kernel.org>
The i_version field in the kernel has had different semantics over
the decades, but we're now proposing to expose it to userland via
statx. This means that we need a clear, consistent definition of
what it means and when it should change.
Update the comments in iversion.h to describe how a conformant
i_version implementation is expected to behave. This definition
suits the current users of i_version (NFSv4 and IMA), but is
loose enough to allow for a wide range of possible implementations.
Cc: Colin Walters <walters@verbum.org>
Cc: NeilBrown <neilb@suse.de>
Cc: Trond Myklebust <trondmy@hammerspace.com>
Cc: Dave Chinner <david@fromorbit.com>
Link: https://lore.kernel.org/linux-xfs/166086932784.5425.17134712694961326033@noble.neil.brown.name/#t
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
include/linux/iversion.h | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/include/linux/iversion.h b/include/linux/iversion.h
index 3bfebde5a1a6..45e93e1b4edc 100644
--- a/include/linux/iversion.h
+++ b/include/linux/iversion.h
@@ -9,8 +9,19 @@
* ---------------------------
* The change attribute (i_version) is mandated by NFSv4 and is mostly for
* knfsd, but is also used for other purposes (e.g. IMA). The i_version must
- * appear different to observers if there was a change to the inode's data or
- * metadata since it was last queried.
+ * appear different to observers if there was an explicit change to the inode's
+ * data or metadata since it was last queried.
+ *
+ * An explicit change is one that would ordinarily result in a change to the
+ * inode status change time (aka ctime). The version must appear to change, even
+ * if the ctime does not (since the whole point is to avoid missing updates due
+ * to timestamp granularity). If POSIX mandates that the ctime must change due
+ * to an operation, then the i_version counter must be incremented as well.
+ *
+ * A conformant implementation is allowed to increment the counter in other
+ * cases, but this is not optimal. NFSv4 and IMA both use this value to determine
+ * whether caches are up to date. Spurious increments can cause false cache
+ * invalidations.
*
* Observers see the i_version as a 64-bit number that never decreases. If it
* remains the same since it was last checked, then nothing has changed in the
@@ -66,6 +77,14 @@
* Storing the value to disk therefore does not count as a query, so those
* filesystems should use inode_peek_iversion to grab the value to be stored.
* There is no need to flag the value as having been queried in that case.
+ *
+ * Notes on atime updates
+ * ----------------------
+ * Access time (atime) updates due to reads or similar activity do not represent
+ * an explicit change to the inode data or metadata. If the only change to the
+ * inode is the atime, then i_version should not be incremented. If an observer
+ * cares about atime updates, it should plan to fetch and store the atime in
+ * conjunction with the i_version.
*/
/*
--
2.37.2
next prev parent reply other threads:[~2022-08-26 21:47 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-26 21:46 [PATCH v3 0/7] vfs: clean up i_version behavior and expose it via statx Jeff Layton
2022-08-26 21:46 ` Jeff Layton [this message]
2022-08-29 7:56 ` [PATCH v3 1/7] iversion: update comments with info about atime updates Dave Chinner
2022-08-29 10:39 ` Jeff Layton
2022-08-29 22:58 ` NeilBrown
2022-08-30 11:40 ` Jeff Layton
2022-08-30 13:24 ` J. Bruce Fields
2022-08-30 13:50 ` Jeff Layton
2022-08-30 14:44 ` J. Bruce Fields
2022-08-30 14:58 ` Trond Myklebust
2022-08-30 15:17 ` J. Bruce Fields
2022-08-30 15:43 ` Trond Myklebust
2022-08-30 17:02 ` Jeff Layton
2022-08-30 17:47 ` Trond Myklebust
2022-08-30 17:53 ` Jeff Layton
2022-08-30 18:25 ` Trond Myklebust
2022-08-30 19:11 ` Jeff Layton
2022-08-30 18:32 ` J. Bruce Fields
2022-08-30 19:30 ` Jeff Layton
2022-08-30 19:46 ` J. Bruce Fields
2022-08-30 19:57 ` Jeff Layton
2022-08-30 20:08 ` J. Bruce Fields
2022-08-30 1:04 ` Dave Chinner
2022-08-30 12:38 ` Jeff Layton
2022-08-26 21:46 ` [PATCH v3 2/7] ext4: fix i_version handling in ext4 Jeff Layton
2022-08-26 21:46 ` [PATCH v3 3/7] ext4: unconditionally enable the i_version counter Jeff Layton
2022-08-29 14:51 ` Jan Kara
2022-08-26 21:47 ` [PATCH v3 4/7] xfs: don't bump the i_version on an atime update in xfs_vn_update_time Jeff Layton
2022-08-27 7:26 ` Amir Goldstein
2022-08-27 8:01 ` Amir Goldstein
2022-08-27 13:14 ` Jeff Layton
2022-08-27 15:46 ` Darrick J. Wong
2022-08-27 16:03 ` Trond Myklebust
2022-08-27 16:10 ` Jeff Layton
2022-08-27 17:06 ` Trond Myklebust
2022-08-28 13:25 ` Amir Goldstein
2022-08-28 14:37 ` Jeff Layton
2022-08-28 16:53 ` Amir Goldstein
2022-08-29 5:48 ` Dave Chinner
2022-08-29 10:33 ` Jeff Layton
2022-08-30 0:08 ` Dave Chinner
2022-08-30 11:20 ` Jeff Layton
2022-08-28 17:30 ` Amir Goldstein
2022-08-26 21:47 ` [PATCH v3 5/7] vfs: report an inode version in statx for IS_I_VERSION inodes Jeff Layton
2022-08-26 21:47 ` [PATCH v3 6/7] nfs: report the inode version in statx if requested Jeff Layton
2022-08-26 21:47 ` [PATCH v3 7/7] 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=20220826214703.134870-2-jlayton@kernel.org \
--to=jlayton@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=lczerner@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ceph@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=trondmy@hammerspace.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=walters@verbum.org \
--cc=xiubli@redhat.com \
--cc=zohar@linux.ibm.com \
/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).