From: Jeff Layton <jlayton@kernel.org>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Chandan Babu R <chandan.babu@oracle.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>, Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <ak@linux.intel.com>,
kernel-team@fb.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-mm@kvack.org, linux-nfs@vger.kernel.org,
Jeff Layton <jlayton@kernel.org>
Subject: [PATCH v2 00/11] fs: multigrain timestamp redux
Date: Mon, 01 Jul 2024 06:26:36 -0400 [thread overview]
Message-ID: <20240701-mgtime-v2-0-19d412a940d9@kernel.org> (raw)
This set is essentially unchanged from the last one, aside from the
new file in Documentation/. I had a review comment from Andi Kleen
suggesting that the ctime_floor should be per time_namespace, but I
think that's incorrect as the realtime clock is not namespaced.
At LSF/MM this year, we had a discussion about the inode change
attribute. At the time I mentioned that I thought I could salvage the
multigrain timestamp work that had to be reverted last year [1]. That
version had to be reverted because it was possible for a file to get a
coarse grained timestamp that appeared to be earlier than another file
that had recently gotten a fine-grained stamp.
This version corrects the problem by establishing a per-time_namespace
ctime_floor value that should prevent this from occurring. In the above
situation that was problematic before, the two files might end up with
the same timestamp value, but they won't appear to have been modified in
the wrong order.
That problem was discovered by the test-stat-time gnulib test. Note that
that test still fails on multigrain timestamps, but that's because its
method of determining the minimum delay that will show a timestamp
change will no longer work with multigrain timestamps. I have a patch to
change the testcase to use a different method that I've posted to the
bug-gnulib mailing list.
The big question with this set is whether the performance will be
suitable. The testing I've done seems to show performance parity with
multigrain timestamps enabled, but it's hard to rule this out regressing
some workload.
This set is based on top of Christian's vfs.misc branch (which has the
earlier change to track inode timestamps as discrete integers). If there
are no major objections, I'd like to let this soak in linux-next for a
bit to see if any problems shake out.
[1]: https://lore.kernel.org/linux-fsdevel/20230807-mgctime-v7-0-d1dec143a704@kernel.org/
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
Changes in v2:
- Added Documentation file
- Link to v1: https://lore.kernel.org/r/20240626-mgtime-v1-0-a189352d0f8f@kernel.org
---
Jeff Layton (11):
fs: turn inode ctime fields into a single ktime_t
fs: uninline inode_get_ctime and inode_set_ctime_to_ts
fs: tracepoints for inode_needs_update_time and inode_set_ctime_to_ts
fs: add infrastructure for multigrain timestamps
fs: add percpu counters to count fine vs. coarse timestamps
fs: have setattr_copy handle multigrain timestamps appropriately
xfs: switch to multigrain timestamps
ext4: switch to multigrain timestamps
btrfs: convert to multigrain timestamps
tmpfs: add support for multigrain timestamps
Documentation: add a new file documenting multigrain timestamps
Documentation/filesystems/multigrain-ts.rst | 126 ++++++++++++++++
fs/attr.c | 52 ++++++-
fs/btrfs/file.c | 25 +---
fs/btrfs/super.c | 3 +-
fs/ext4/super.c | 2 +-
fs/inode.c | 221 +++++++++++++++++++++++++---
fs/stat.c | 39 ++++-
fs/xfs/libxfs/xfs_trans_inode.c | 6 +-
fs/xfs/xfs_iops.c | 6 +-
fs/xfs/xfs_super.c | 2 +-
include/linux/fs.h | 61 +++++---
include/trace/events/timestamp.h | 173 ++++++++++++++++++++++
mm/shmem.c | 2 +-
13 files changed, 639 insertions(+), 79 deletions(-)
---
base-commit: 2e8c78ef85682671dae2ac3a5aa039b07be0fc0b
change-id: 20240626-mgtime-5cd80b18d810
Best regards,
--
Jeff Layton <jlayton@kernel.org>
next reply other threads:[~2024-07-01 10:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 10:26 Jeff Layton [this message]
2024-07-01 10:26 ` [PATCH v2 01/11] fs: turn inode ctime fields into a single ktime_t Jeff Layton
2024-07-01 10:26 ` [PATCH v2 02/11] fs: uninline inode_get_ctime and inode_set_ctime_to_ts Jeff Layton
2024-07-01 10:26 ` [PATCH v2 03/11] fs: tracepoints for inode_needs_update_time " Jeff Layton
2024-07-01 10:26 ` [PATCH v2 04/11] fs: add infrastructure for multigrain timestamps Jeff Layton
2024-07-01 10:26 ` [PATCH v2 05/11] fs: add percpu counters to count fine vs. coarse timestamps Jeff Layton
2024-07-01 10:26 ` [PATCH v2 06/11] fs: have setattr_copy handle multigrain timestamps appropriately Jeff Layton
2024-07-01 10:26 ` [PATCH v2 07/11] xfs: switch to multigrain timestamps Jeff Layton
2024-07-01 13:46 ` Josef Bacik
2024-07-01 10:26 ` [PATCH v2 08/11] ext4: " Jeff Layton
2024-07-01 10:26 ` [PATCH v2 09/11] btrfs: convert " Jeff Layton
2024-07-01 13:49 ` Josef Bacik
2024-07-01 13:57 ` Jeff Layton
2024-07-01 15:24 ` David Sterba
2024-07-01 20:33 ` Josef Bacik
2024-07-01 10:26 ` [PATCH v2 10/11] tmpfs: add support for " Jeff Layton
2024-07-01 10:26 ` [PATCH v2 11/11] Documentation: add a new file documenting " Jeff Layton
2024-07-01 13:52 ` Josef Bacik
2024-07-01 13:53 ` [PATCH v2 00/11] fs: multigrain timestamp redux Josef Bacik
2024-07-01 14:12 ` 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=20240701-mgtime-v2-0-19d412a940d9@kernel.org \
--to=jlayton@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=clm@fb.com \
--cc=djwong@kernel.org \
--cc=dsterba@suse.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.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-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tytso@mit.edu \
--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;
as well as URLs for NNTP newsgroup(s).