cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH v2 00/89] fs: new accessors for inode->i_ctime
Date: Thu, 06 Jul 2023 12:14:58 -0400	[thread overview]
Message-ID: <3948ae7653d1cb7c51febcca26a35775e71a53b4.camel@kernel.org> (raw)
In-Reply-To: <87ilaxgjek.fsf@email.froward.int.ebiederm.org>

On Thu, 2023-07-06 at 10:16 -0500, Eric W. Biederman wrote:
> Jeff Layton <jlayton@kernel.org> writes:
> 
> > On Wed, 2023-07-05 at 14:58 -0400, Jeff Layton wrote:
> > > v2:
> > > - prepend patches to add missing ctime updates
> > > - add simple_rename_timestamp helper function
> > > - rename ctime accessor functions as inode_get_ctime/inode_set_ctime_*
> > > - drop individual inode_ctime_set_{sec,nsec} helpers
> > > 
> > > I've been working on a patchset to change how the inode->i_ctime is
> > > accessed in order to give us conditional, high-res timestamps for the
> > > ctime and mtime. struct timespec64 has unused bits in it that we can use
> > > to implement this. In order to do that however, we need to wrap all
> > > accesses of inode->i_ctime to ensure that bits used as flags are
> > > appropriately handled.
> > > 
> > > The patchset starts with reposts of some missing ctime updates that I
> > > spotted in the tree. It then adds a new helper function for updating the
> > > timestamp after a successful rename, and new ctime accessor
> > > infrastructure.
> > > 
> > > The bulk of the patchset is individual conversions of different
> > > subsysteme to use the new infrastructure. Finally, the patchset renames
> > > the i_ctime field to __i_ctime to help ensure that I didn't miss
> > > anything.
> > > 
> > > This should apply cleanly to linux-next as of this morning.
> > > 
> > > Most of this conversion was done via 5 different coccinelle scripts, run
> > > in succession, with a large swath of by-hand conversions to clean up the
> > > remainder.
> > > 
> > 
> > A couple of other things I should note:
> > 
> > If you sent me an Acked-by or Reviewed-by in the previous set, then I
> > tried to keep it on the patch here, since the respun patches are mostly
> > just renaming stuff from v1. Let me know if I've missed any.
> > 
> > I've also pushed the pile to my tree as this tag:
> > 
> >     https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/tag/?h=ctime.20230705
> > 
> > In case that's easier to work with.
> 
> Are there any preliminary patches showing what you want your introduced
> accessors to turn into?  It is hard to judge the sanity of the
> introduction of wrappers without seeing what the wrappers are ultimately
> going to do.
> 
> Eric

I have a draft version of the multigrain patches on top of the wrapper
conversion I've already posted in my "mgctime-experimental" branch:

    https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/log/?h=mgctime-experimental

The rationale is best explained in this changelog:

    https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/commit/?h=mgctime-experimental&id=face437a144d3375afb7f70c233b0644b4edccba

The idea will be to enable this on a per-fs basis.
-- 
Jeff Layton <jlayton@kernel.org>


  reply	other threads:[~2023-07-06 16:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-05 18:58 [Cluster-devel] [PATCH v2 00/89] fs: new accessors for inode->i_ctime Jeff Layton
2023-07-05 18:58 ` [Cluster-devel] [PATCH v2 07/92] fs: add ctime accessors infrastructure Jeff Layton
2023-07-05 23:12   ` Damien Le Moal
2023-07-05 18:58 ` [Cluster-devel] [PATCH v2 08/92] fs: new helper: simple_rename_timestamp Jeff Layton
2023-07-05 23:19   ` Damien Le Moal
2023-07-06  0:04     ` Jeff Layton
2023-07-06 21:02       ` [Cluster-devel] [apparmor] " Seth Arnold
2023-07-07 10:50         ` Jeff Layton
2023-07-06 10:27   ` [Cluster-devel] " Jan Kara
2023-08-30  0:19   ` Al Viro
2023-08-30  0:48     ` Jeff Layton
2023-07-05 18:58 ` [Cluster-devel] [PATCH v2 92/92] fs: rename i_ctime field to __i_ctime Jeff Layton
2023-07-05 23:19   ` Damien Le Moal
2023-07-06 14:58   ` Jan Kara
2023-07-05 21:57 ` [Cluster-devel] [PATCH v2 00/89] fs: new accessors for inode->i_ctime Jeff Layton
2023-07-06 15:16   ` Eric W. Biederman
2023-07-06 16:14     ` Jeff Layton [this message]
2023-07-07 12:42 ` Jeff Layton
2023-07-10 12:35   ` Christian Brauner
2023-07-10 13:32     ` Jeff Layton
2023-07-10 12:18 ` [Cluster-devel] [PATCH v2 00/92] " Christian Brauner
2023-09-04 18:11 ` [Cluster-devel] [f2fs-dev] [PATCH v2 00/89] " patchwork-bot+f2fs

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=3948ae7653d1cb7c51febcca26a35775e71a53b4.camel@kernel.org \
    --to=jlayton@kernel.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).