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>
next prev parent 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).