From: Josef Bacik <josef@toxicpanda.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: 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>, David Sterba <dsterba@suse.com>,
Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
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
Subject: Re: [PATCH v2 00/11] fs: multigrain timestamp redux
Date: Mon, 1 Jul 2024 09:53:32 -0400 [thread overview]
Message-ID: <20240701135332.GD504479@perftesting> (raw)
In-Reply-To: <20240701-mgtime-v2-0-19d412a940d9@kernel.org>
On Mon, Jul 01, 2024 at 06:26:36AM -0400, Jeff Layton wrote:
> 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>
I have a few nits that need to be addressed, but you can add
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
to the series once they're addressed. Thanks,
Josef
next prev parent reply other threads:[~2024-07-01 13:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 10:26 [PATCH v2 00/11] fs: multigrain timestamp redux Jeff Layton
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 ` Josef Bacik [this message]
2024-07-01 14:12 ` [PATCH v2 00/11] fs: multigrain timestamp redux 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=20240701135332.GD504479@perftesting \
--to=josef@toxicpanda.com \
--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=jlayton@kernel.org \
--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 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.