linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jan Kara <jack@suse.cz>, Jeff Layton <jlayton@kernel.org>
Subject: [GIT PULL v2] timestamp fixes
Date: Thu, 21 Sep 2023 13:20:46 +0200	[thread overview]
Message-ID: <20230921-umgekehrt-buden-a8718451ef7c@brauner> (raw)

Hey Linus,

/* Summary */
Earlier this week we sent a few minor fixes for the multi-grained
timestamp work in [1]. While we were polishing those up after Linus
realized that there might be a nicer way to fix them we received a
regression report in [2] that fine grained timestamps break gnulib tests
and thus possibly other tools.

The kernel will elide fine-grain timestamp updates when no one is
actively querying for them to avoid performance impacts. So a sequence
like write(f1) stat(f2) write(f2) stat(f2) write(f1) stat(f1) may result
in timestamp f1 to be older than the final f2 timestamp even though f1
was last written too but the second write didn't update the timestamp.

Such plotholes can lead to subtle bugs when programs compare timestamps.
For example, the nap() function in [2] will estimate that it needs to
wait one ns on a fine-grain timestamp enabled filesytem between
subsequent calls to observe a timestamp change. But in general we don't
update timestamps with more than one jiffie if we think that no one is
actively querying for fine-grain timestamps to avoid performance
impacts.

While discussing various fixes the decision was to go back to the
drawing board and ultimately to explore a solution that involves only
exposing such fine-grained timestamps to nfs internally and never to
userspace.

As there are multiple solutions discussed the honest thing to do here is
not to fix this up or disable it but to cleanly revert. The general
infrastructure will probably come back but there is no reason to keep
this code in mainline.

The general changes to timestamp handling are valid and a good cleanup
that will stay. The revert is fully bisectable.

Link: [1]: https://lore.kernel.org/all/20230918-hirte-neuzugang-4c2324e7bae3@brauner
Link: [2]: https://lore.kernel.org/all/bf0524debb976627693e12ad23690094e4514303.camel@linuxfromscratch.org

/* Testing */
clang: Ubuntu clang version 15.0.7
gcc: (Ubuntu 12.2.0-3ubuntu1) 12.2.0

All patches are based on v6.5-rc1 and have been sitting in linux-next.
No build failures or warnings were observed. xfstests pass without
regressions.

/* Conflicts */
At the time of creating this PR no merge conflicts were reported from
linux-next and no merge conflicts showed up doing a test-merge with
current mainline.

The following changes since commit ce9ecca0238b140b88f43859b211c9fdfd8e5b70:

  Linux 6.6-rc2 (2023-09-17 14:40:24 -0700)

are available in the Git repository at:

  git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/v6.6-rc3.vfs.ctime.revert

for you to fetch changes up to 647aa768281f38cb1002edb3a1f673c3d66a8d81:

  Revert "fs: add infrastructure for multigrain timestamps" (2023-09-20 18:05:31 +0200)

Please consider pulling these changes from the signed v6.6-rc3.vfs.ctime.revert tag.

Thanks!
Christian

----------------------------------------------------------------
v6.6-rc3.vfs.ctime.revert

----------------------------------------------------------------
Christian Brauner (5):
      Revert "tmpfs: add support for multigrain timestamps"
      Revert "xfs: switch to multigrain timestamps"
      Revert "ext4: switch to multigrain timestamps"
      Revert "btrfs: convert to multigrain timestamps"
      Revert "fs: add infrastructure for multigrain timestamps"

 fs/btrfs/file.c                 | 24 ++++++++++--
 fs/btrfs/super.c                |  5 +--
 fs/ext4/super.c                 |  2 +-
 fs/inode.c                      | 82 ++---------------------------------------
 fs/stat.c                       | 41 +--------------------
 fs/xfs/libxfs/xfs_trans_inode.c |  6 +--
 fs/xfs/xfs_iops.c               |  6 +--
 fs/xfs/xfs_super.c              |  2 +-
 include/linux/fs.h              | 46 +----------------------
 mm/shmem.c                      |  2 +-
 10 files changed, 38 insertions(+), 178 deletions(-)

             reply	other threads:[~2023-09-21 20:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-21 11:20 Christian Brauner [this message]
2023-09-21 18:24 ` [GIT PULL v2] timestamp fixes Linus Torvalds
2023-09-21 18:51   ` Jeff Layton
2023-09-21 19:28     ` Linus Torvalds
2023-09-21 19:46       ` Linus Torvalds
2023-09-21 21:57         ` Jeff Layton
2023-09-22 12:28           ` Christian Brauner
2023-09-22 10:19       ` David Sterba
2023-09-23  6:36       ` Amir Goldstein
2023-09-23 17:48         ` Linus Torvalds
2023-09-23 19:30           ` Theodore Ts'o
2023-09-23 20:03             ` Linus Torvalds
2023-09-23 22:07               ` Theodore Ts'o
2023-09-23 23:31                 ` Linus Torvalds
2023-09-23 21:29           ` Amir Goldstein
2023-09-24 10:26             ` Christian Brauner
2023-09-25 11:22           ` Jeff Layton
2023-09-25 16:02             ` Linus Torvalds
2023-09-22 12:24     ` Christian Brauner
2023-09-24  8:34     ` Amir Goldstein
2023-09-24 10:15       ` Christian Brauner
2023-09-22 12:16   ` Christian Brauner
2023-09-21 20:10 ` pr-tracker-bot

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=20230921-umgekehrt-buden-a8718451ef7c@brauner \
    --to=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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).