[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240626-mgtime-v1-0-a189352d0f8f@kernel.org>
Date: Wed, 26 Jun 2024 21:00:20 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Chandan Babu R <chandan.babu@...cle.com>,
"Darrick J. Wong" <djwong@...nel.org>, Theodore Ts'o <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>, Chris Mason <clm@...com>,
Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>,
Hugh Dickins <hughd@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>
Cc: kernel-team@...com, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
linux-xfs@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-btrfs@...r.kernel.org, linux-mm@...ck.org, linux-nfs@...r.kernel.org,
Jeff Layton <jlayton@...nel.org>
Subject: [PATCH 00/10] fs: multigrain timestamp redux
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 global 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 will post soon.
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@...nel.org>
---
Jeff Layton (10):
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
fs/attr.c | 52 +++++++--
fs/btrfs/file.c | 25 +----
fs/btrfs/super.c | 3 +-
fs/ext4/super.c | 2 +-
fs/inode.c | 222 +++++++++++++++++++++++++++++++++++----
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 +-
12 files changed, 514 insertions(+), 79 deletions(-)
---
base-commit: 33b321ac3a51e590225585f41c7412b86e987a0d
change-id: 20240626-mgtime-5cd80b18d810
Best regards,
--
Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists