linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-ext4@vger.kernel.org, NeilBrown <neilb@suse.de>,
	Trond Myklebust <trondmy@hammerspace.com>,
	Dave Chinner <david@fromorbit.com>
Subject: [PATCH] iversion: update comments with info about atime updates
Date: Mon, 22 Aug 2022 09:33:09 -0400	[thread overview]
Message-ID: <20220822133309.86005-1-jlayton@kernel.org> (raw)

Add an explicit paragraph codifying that atime updates due to reads
should not be counted against the i_version counter. None of the
existing subsystems that use the i_version want those counted, and
there is an easy workaround for those that do.

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 | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/iversion.h b/include/linux/iversion.h
index 3bfebde5a1a6..da6cc1cc520a 100644
--- a/include/linux/iversion.h
+++ b/include/linux/iversion.h
@@ -9,8 +9,8 @@
  * ---------------------------
  * 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.
  *
  * 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
@@ -18,6 +18,12 @@
  * anything about the nature or magnitude of the changes from the value, only
  * that the inode has changed in some fashion.
  *
+ * Note that atime updates due to reads or similar activity do _not_ represent
+ * an explicit change to the inode. If the only change is to the atime and it
+ * wasn't set via utimes() or a similar mechanism, then i_version should not be
+ * incremented. If an observer cares about atime updates, it should plan to
+ * fetch and store them in conjunction with the i_version.
+ *
  * Not all filesystems properly implement the i_version counter. Subsystems that
  * want to use i_version field on an inode should first check whether the
  * filesystem sets the SB_I_VERSION flag (usually via the IS_I_VERSION macro).
-- 
2.37.2


             reply	other threads:[~2022-08-22 13:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-22 13:33 Jeff Layton [this message]
2022-08-22 15:40 ` [PATCH] iversion: update comments with info about atime updates Mimi Zohar
2022-08-22 16:22   ` Jeff Layton
2022-08-22 17:39     ` Mimi Zohar
2022-08-22 18:22       ` Jeff Layton
2022-08-22 23:32         ` Dave Chinner
2022-08-23 11:21           ` Jeff Layton
2022-08-23 11:38             ` NeilBrown
2022-08-23 11:51               ` Jeff Layton
2022-08-23 22:24                 ` NeilBrown
2022-08-23 23:28                   ` Dave Chinner
2022-08-23 23:42                     ` NeilBrown
2022-08-24  0:11                       ` Trond Myklebust
2022-08-24 12:53                   ` Jeff Layton
2022-08-25  0:17                     ` NeilBrown
2022-08-23 23:25             ` Dave Chinner
2022-08-24 12:45               ` Jeff Layton
2022-08-22 22:42 ` NeilBrown
2022-08-22 23:26   ` Trond Myklebust

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=20220822133309.86005-1-jlayton@kernel.org \
    --to=jlayton@kernel.org \
    --cc=david@fromorbit.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@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 \
    /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).