linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dave Chinner <david@fromorbit.com>,
	Chuck Lever <chuck.lever@oracle.com>
Cc: Jan Kara <jack@suse.cz>, Amir Goldstein <amir73il@gmail.com>,
	David Howells <dhowells@redhat.com>, Neil Brown <neilb@suse.de>,
	Matthew Wilcox <willy@infradead.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Theodore T'so <tytso@mit.edu>, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-ext4@vger.kernel.org, linux-mm@kvack.org,
	linux-nfs@vger.kernel.org
Subject: [PATCH v3 0/6] fs: implement multigrain timestamps
Date: Wed,  3 May 2023 10:20:31 -0400	[thread overview]
Message-ID: <20230503142037.153531-1-jlayton@kernel.org> (raw)

Major changes in v3:
- move flag to use bit 31 instead of 0 since the upper bits in the
  tv_nsec field aren't used for timestamps. This means we don't need to
  set s_time_gran to a value higher than 1.

- use an fstype flag instead of a superblock flag

...plus a lot of smaller cleanups and documentation.

The basic idea with multigrain timestamps is to keep track of when an
inode's mtime or ctime has been queried and to force a fine-grained
timestamp the next time the mtime or ctime is updated.

This is a follow-up of the patches I posted last week [1]. The main
change in this set is that it no longer uses the lowest-order bit in the
tv_nsec field, and instead uses one of the higher-order bits (#31,
specifically) since they are otherwise unused. This change makes things
much simpler, and we no longer need to twiddle s_time_gran for it.

Note that with these changes, the statx06 LTP test will intermittently
fail on most filesystems, usually with errors like this:

    statx06.c:138: TFAIL: Birth time > after_time
    statx06.c:138: TFAIL: Modified time > after_time

The test does this:

        SAFE_CLOCK_GETTIME(CLOCK_REALTIME_COARSE, &before_time);
        clock_wait_tick();
        tc->operation();
        clock_wait_tick();
        SAFE_CLOCK_GETTIME(CLOCK_REALTIME_COARSE, &after_time);

Converting the second SAFE_CLOCK_GETTIME to use CLOCK_REALTIME instead
gets things working again.

For now, I've only converted/tested a few filesystems, focusing on the
most popular ones exported via NFS.  If this approach looks acceptable
though, I'll plan to convert more filesystems to it.

Another thing we could consider is enabling this unilaterally
kernel-wide. I decided not to do that for now, but it's something we
could consider for lately.

[1]: https://lore.kernel.org/linux-fsdevel/20230424151104.175456-1-jlayton@kernel.org/

Jeff Layton (6):
  fs: add infrastructure for multigrain inode i_m/ctime
  overlayfs: allow it handle multigrain timestamps
  shmem: convert to multigrain timestamps
  xfs: convert to multigrain timestamps
  ext4: convert to multigrain timestamps
  btrfs: convert to multigrain timestamps

 fs/btrfs/delayed-inode.c        |  2 +-
 fs/btrfs/file.c                 | 10 +++---
 fs/btrfs/inode.c                | 25 +++++++-------
 fs/btrfs/ioctl.c                |  6 ++--
 fs/btrfs/reflink.c              |  2 +-
 fs/btrfs/super.c                |  5 +--
 fs/btrfs/transaction.c          |  2 +-
 fs/btrfs/tree-log.c             |  2 +-
 fs/btrfs/volumes.c              |  2 +-
 fs/btrfs/xattr.c                |  4 +--
 fs/ext4/acl.c                   |  2 +-
 fs/ext4/extents.c               | 10 +++---
 fs/ext4/ialloc.c                |  2 +-
 fs/ext4/inline.c                |  4 +--
 fs/ext4/inode.c                 | 24 ++++++++++---
 fs/ext4/ioctl.c                 |  8 ++---
 fs/ext4/namei.c                 | 20 +++++------
 fs/ext4/super.c                 |  4 +--
 fs/ext4/xattr.c                 |  2 +-
 fs/inode.c                      | 52 ++++++++++++++++++++++++++--
 fs/overlayfs/file.c             |  7 ++--
 fs/overlayfs/util.c             |  2 +-
 fs/stat.c                       | 32 +++++++++++++++++
 fs/xfs/libxfs/xfs_inode_buf.c   |  2 +-
 fs/xfs/libxfs/xfs_trans_inode.c |  2 +-
 fs/xfs/xfs_acl.c                |  2 +-
 fs/xfs/xfs_bmap_util.c          |  2 +-
 fs/xfs/xfs_inode.c              |  2 +-
 fs/xfs/xfs_inode_item.c         |  2 +-
 fs/xfs/xfs_iops.c               | 15 ++++++--
 fs/xfs/xfs_super.c              |  2 +-
 include/linux/fs.h              | 61 ++++++++++++++++++++++++++++++++-
 mm/shmem.c                      | 25 +++++++-------
 33 files changed, 255 insertions(+), 89 deletions(-)

-- 
2.40.1


             reply	other threads:[~2023-05-03 14:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03 14:20 Jeff Layton [this message]
2023-05-03 14:20 ` [PATCH v3 1/6] fs: add infrastructure for multigrain inode i_m/ctime Jeff Layton
2023-05-05  0:10   ` Dave Chinner
2023-05-03 14:20 ` [PATCH v3 2/6] overlayfs: allow it handle multigrain timestamps Jeff Layton
2023-05-03 14:20 ` [PATCH v3 3/6] shmem: convert to " Jeff Layton
2023-05-03 14:20 ` [PATCH v3 4/6] xfs: " Jeff Layton
2023-05-03 14:20 ` [PATCH v3 5/6] ext4: " Jeff Layton
2023-05-03 14:20 ` [PATCH v3 6/6] btrfs: " 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=20230503142037.153531-1-jlayton@kernel.org \
    --to=jlayton@kernel.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=clm@fb.com \
    --cc=david@fromorbit.com \
    --cc=dhowells@redhat.com \
    --cc=djwong@kernel.org \
    --cc=dsterba@suse.com \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=josef@toxicpanda.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-xfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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).