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,
bfields@fieldses.org, brauner@kernel.org, fweimer@redhat.com
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, ceph-devel@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 v8 RESEND 2/8] fs: clarify when the i_version counter must be updated
Date: Tue, 24 Jan 2023 14:30:19 -0500 [thread overview]
Message-ID: <20230124193025.185781-3-jlayton@kernel.org> (raw)
In-Reply-To: <20230124193025.185781-1-jlayton@kernel.org>
The i_version field in the kernel has had different semantics over
the decades, but NFSv4 has certain expectations. Update the comments
in iversion.h to describe when the i_version must change.
Cc: Colin Walters <walters@verbum.org>
Cc: NeilBrown <neilb@suse.de>
Cc: Trond Myklebust <trondmy@hammerspace.com>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
include/linux/iversion.h | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/linux/iversion.h b/include/linux/iversion.h
index 6755d8b4f20b..fced8115a5f4 100644
--- a/include/linux/iversion.h
+++ b/include/linux/iversion.h
@@ -9,8 +9,25 @@
* ---------------------------
* 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 larger 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). i_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 or other relevant spec mandates that the
+ * ctime must change due to an operation, then the i_version counter must be
+ * incremented as well.
+ *
+ * Making the i_version update completely atomic with the operation itself would
+ * be prohibitively expensive. Traditionally the kernel has updated the times on
+ * directories after an operation that changes its contents. For regular files,
+ * the ctime is usually updated before the data is copied into the cache for a
+ * write. This means that there is a window of time when an observer can
+ * associate a new timestamp with old file contents. Since the purpose of the
+ * i_version is to allow for better cache coherency, the i_version must always
+ * be updated after the results of the operation are visible. Updating it before
+ * and after a change is also permitted.
*
* 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
--
2.39.1
next prev parent reply other threads:[~2023-01-24 19:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 19:30 [PATCH v8 RESEND 0/8] fs: clean up internal i_version handling Jeff Layton
2023-01-24 19:30 ` [PATCH v8 RESEND 1/8] fs: uninline inode_query_iversion Jeff Layton
2023-01-25 13:44 ` Jan Kara
2023-01-26 9:02 ` Christian Brauner
2023-01-24 19:30 ` Jeff Layton [this message]
2023-01-25 16:06 ` [PATCH v8 RESEND 2/8] fs: clarify when the i_version counter must be updated Jan Kara
2023-01-26 10:54 ` Jeff Layton
2023-01-26 11:36 ` Jan Kara
2023-01-26 12:02 ` Jeff Layton
2023-01-26 9:01 ` Christian Brauner
2023-01-24 19:30 ` [PATCH v8 RESEND 3/8] vfs: plumb i_version handling into struct kstat Jeff Layton
2023-01-25 15:50 ` Christian Brauner
2023-01-25 18:30 ` Jeff Layton
2023-01-26 8:23 ` Christian Brauner
2023-01-25 16:20 ` Jan Kara
2023-01-24 19:30 ` [PATCH v8 RESEND 4/8] nfs: report the inode version in getattr if requested Jeff Layton
2023-01-24 19:30 ` [PATCH v8 RESEND 5/8] ceph: " Jeff Layton
2023-01-24 19:30 ` [PATCH v8 RESEND 6/8] nfsd: move nfsd4_change_attribute to nfsfh.c Jeff Layton
2023-01-24 19:30 ` [PATCH v8 RESEND 7/8] nfsd: use the getattr operation to fetch i_version Jeff Layton
2023-01-24 19:30 ` [PATCH v8 RESEND 8/8] nfsd: remove fetch_iversion export operation 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=20230124193025.185781-3-jlayton@kernel.org \
--to=jlayton@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=bfields@fieldses.org \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=chuck.lever@oracle.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=fweimer@redhat.com \
--cc=jack@suse.cz \
--cc=lczerner@redhat.com \
--cc=linux-btrfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.