All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 9/9] xfs: add in-memory iunlink log item
Date: Thu, 30 Jun 2022 07:37:23 +1000	[thread overview]
Message-ID: <20220629213723.GY227878@dread.disaster.area> (raw)
In-Reply-To: <Yrv+gfvrtIFOwami@infradead.org>

On Wed, Jun 29, 2022 at 12:25:53AM -0700, Christoph Hellwig wrote:
> On Mon, Jun 27, 2022 at 10:43:36AM +1000, Dave Chinner wrote:
> > TO do this, we introduce a new in-memory log item to track the
> 
> s/To/To/
> 
> > This allows us to pass the xfs_inode to the transaction commit code
> > along with the modification to be made, and then order the logged
> > modifications via the ->iop_sort and ->iop_precommit operations
> > for the new log item type. As this is an in-memory log item, it
> > doesn't have formatting, CIL or AIL operational hooks - it exists
> > purely to run the inode unlink modifications and is then removed
> > from the transaction item list and freed once the precommit
> > operation has run.
> 
> Do we need to document the fact that we now have purely in-memory log
> items better somewhere?  I see how this works, but it its a little
> non-obvious.

We already have in-memory log items, just not explicitly named. That
is, the transaction delta structures for the superblock and dquot
modifications.

I eventually want to move them to in-memory log items to get all the
special case code for them out of the transaction commit path, and
then add in-memory log items for AGF and AGI header modifications so
that we can move away from AG header buffer locking to serialise AG
specific operations...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2022-06-29 21:37 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27  0:43 [PATCH 0/9 v3] xfs: in-memory iunlink items Dave Chinner
2022-06-27  0:43 ` [PATCH 1/9] xfs: factor the xfs_iunlink functions Dave Chinner
2022-06-29  7:05   ` Christoph Hellwig
2022-06-29 20:48   ` Darrick J. Wong
2022-06-27  0:43 ` [PATCH 2/9] xfs: track the iunlink list pointer in the xfs_inode Dave Chinner
2022-06-29  7:08   ` Christoph Hellwig
2022-06-29 20:50   ` Darrick J. Wong
2022-06-27  0:43 ` [PATCH 3/9] xfs: refactor xlog_recover_process_iunlinks() Dave Chinner
2022-06-29  7:12   ` Christoph Hellwig
2022-06-29 20:56   ` Darrick J. Wong
2022-06-27  0:43 ` [PATCH 4/9] xfs: introduce xfs_iunlink_lookup Dave Chinner
2022-06-29  7:17   ` Christoph Hellwig
2022-06-29 21:01   ` Darrick J. Wong
2022-06-27  0:43 ` [PATCH 5/9] xfs: double link the unlinked inode list Dave Chinner
2022-06-29  7:20   ` Christoph Hellwig
2022-06-29 20:02     ` Darrick J. Wong
2022-06-29 21:06   ` Darrick J. Wong
2022-06-27  0:43 ` [PATCH 6/9] xfs: clean up xfs_iunlink_update_inode() Dave Chinner
2022-06-29  7:21   ` Christoph Hellwig
2022-06-29 21:07   ` Darrick J. Wong
2022-06-27  0:43 ` [PATCH 7/9] xfs: combine iunlink inode update functions Dave Chinner
2022-06-29  7:21   ` Christoph Hellwig
2022-06-29 21:07   ` Darrick J. Wong
2022-06-27  0:43 ` [PATCH 8/9] xfs: add log item precommit operation Dave Chinner
2022-06-29 21:16   ` Darrick J. Wong
2022-06-29 21:34     ` Dave Chinner
2022-06-29 21:42       ` Darrick J. Wong
2022-06-29 21:48         ` Dave Chinner
2022-07-07  2:34           ` Darrick J. Wong
2022-06-27  0:43 ` [PATCH 9/9] xfs: add in-memory iunlink log item Dave Chinner
2022-06-29  7:25   ` Christoph Hellwig
2022-06-29 21:37     ` Dave Chinner [this message]
2022-06-29 21:21   ` Darrick J. Wong
2022-06-29 21:44     ` Dave Chinner
2022-06-29 21:49       ` Darrick J. Wong
2022-07-07 23:43 [PATCH 0/9 v4] xfs: introduce in-memory inode unlink log items Dave Chinner
2022-07-07 23:43 ` [PATCH 9/9] xfs: add in-memory iunlink log item Dave Chinner
2022-07-11  5:24   ` Christoph Hellwig

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=20220629213723.GY227878@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.