linux-fsdevel.vger.kernel.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>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-mm@kvack.org,
	linux-nfs@vger.kernel.org
Subject: [PATCH v2 0/3] fs: multigrain timestamps
Date: Mon, 24 Apr 2023 11:11:01 -0400	[thread overview]
Message-ID: <20230424151104.175456-1-jlayton@kernel.org> (raw)

A few weeks ago, during one of the discussions around i_version, Dave
Chinner wrote this:

"You've missed the part where I suggested lifting the "nfsd sampled
i_version" state into an inode state flag rather than hiding it in
the i_version field. At that point, we could optimise away the
secondary ctime updates just like you are proposing we do with the
i_version updates.  Further, we could also use that state it to
decide whether we need to use high resolution timestamps when
recording ctime updates - if the nfsd has not sampled the
ctime/i_version, we don't need high res timestamps to be recorded
for ctime...."

While I don't think we can practically optimize away ctime updates
like we do with i_version, I do like the idea of using this scheme to
indicate when we need to use a high-res timestamp.

This patchset is a second attempt at implementing this. The main
difference with this set is that it uses the lowest-order bit of the
tv_nsec field as the flag instead of using an i_state flag. This also
allows us to use atomic ops instead of a spinlock.

With this, the patchset also contains a new opt-in mechanism: You must
set a SB_MULTIGRAIN_TS flag in the superblock, and also raise your
sb->s_time_gran to at least 2.

The first patch adds the necessary infrastructure, and the last two
patches convert tmpfs and xfs to use it. If this looks good, I'll start
embarking on converting other filesystems to this scheme as well.

Comments and suggestions welcome!

Jeff Layton (3):
  fs: add infrastructure for multigrain inode i_m/ctime
  shmem: mark for high-res timestamps on next update after getattr
  xfs: mark the inode for high-res timestamp update in getattr

 fs/inode.c                      | 57 +++++++++++++++++++++++++++---
 fs/stat.c                       | 24 +++++++++++++
 fs/xfs/libxfs/xfs_trans_inode.c |  2 +-
 fs/xfs/xfs_acl.c                |  2 +-
 fs/xfs/xfs_inode.c              |  2 +-
 fs/xfs/xfs_inode_item.c         |  2 +-
 fs/xfs/xfs_iops.c               |  9 +++--
 fs/xfs/xfs_super.c              |  5 ++-
 include/linux/fs.h              | 62 +++++++++++++++++++++++----------
 mm/shmem.c                      | 29 ++++++++-------
 10 files changed, 152 insertions(+), 42 deletions(-)

-- 
2.40.0


             reply	other threads:[~2023-04-24 15:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-24 15:11 Jeff Layton [this message]
2023-04-24 15:11 ` [PATCH v2 1/3] fs: add infrastructure for multigrain inode i_m/ctime Jeff Layton
2023-04-24 21:47   ` NeilBrown
2023-04-24 22:30     ` Jeff Layton
2023-04-24 22:40       ` NeilBrown
2023-04-25 17:45         ` Jeff Layton
2023-04-25 17:56           ` Matthew Wilcox
2023-04-25 19:12             ` Jeff Layton
2023-04-26  6:41       ` Christian Brauner
2023-04-26  6:53   ` Christian Brauner
2023-04-26  9:46     ` Jeff Layton
2023-04-27  9:44       ` Christian Brauner
2023-04-26  7:07   ` Christian Brauner
2023-04-26  9:48     ` Jeff Layton
2023-04-27  9:51       ` Christian Brauner
2023-04-27  9:57         ` Jeff Layton
2023-04-24 15:11 ` [PATCH v2 2/3] shmem: mark for high-res timestamps on next update after getattr Jeff Layton
2023-04-24 15:11 ` [PATCH v2 3/3] xfs: mark the inode for high-res timestamp update in getattr 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=20230424151104.175456-1-jlayton@kernel.org \
    --to=jlayton@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --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=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).