public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 0/5] xfs: fix how we deal with new intents during recovery
@ 2020-09-29 17:43 Darrick J. Wong
  2020-09-29 17:43 ` [PATCH 1/5] xfs: remove xfs_defer_reset Darrick J. Wong
                   ` (4 more replies)
  0 siblings, 5 replies; 24+ messages in thread
From: Darrick J. Wong @ 2020-09-29 17:43 UTC (permalink / raw)
  To: darrick.wong
  Cc: Dave Chinner, Christoph Hellwig, linux-xfs, david, hch, bfoster

Hi all,

This series of log fixes dates back to an earlier discussion that Dave
and I had about the weird way that log recovery works w.r.t. intent
items.  The current code juggles nested transactions so that it can
siphon off new deferred items for later; this we replace with a new
dfops freezer that captures the log reservation type and remaining block
reservation so that we finish the new deferred items with the same
transaction context as we would have had the system not gone down.

v2: rework the defer capture api per hch suggestions
v3: rework the api again, per bfoster suggestions, so now xfs_defer_capture
is only responsible for creating the capture device, and log recovery still
has to do some work to commit a transaction and free resources
v4: kill XFS_LI_RECOVERED and move all the defer capture commit and release
code to xfs_defer.c

If you're going to start using this mess, you probably ought to just
pull from my git trees, which are linked below.

This is an extraordinary way to destroy everything.  Enjoy!
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=fix-recovery-intent-chaining-5.10
---
 fs/xfs/libxfs/xfs_defer.c  |  127 +++++++++++++++++++++++++++++++++++---------
 fs/xfs/libxfs/xfs_defer.h  |   21 +++++++
 fs/xfs/xfs_bmap_item.c     |   16 +-----
 fs/xfs/xfs_extfree_item.c  |    7 +-
 fs/xfs/xfs_log_recover.c   |  110 +++++++++++++++++++-------------------
 fs/xfs/xfs_refcount_item.c |   16 +-----
 fs/xfs/xfs_rmap_item.c     |    7 +-
 fs/xfs/xfs_trans.h         |    7 +-
 8 files changed, 193 insertions(+), 118 deletions(-)


^ permalink raw reply	[flat|nested] 24+ messages in thread
* [PATCH v5 0/5] xfs: fix how we deal with new intents during recovery
@ 2020-10-05 18:19 Darrick J. Wong
  2020-10-05 18:20 ` [PATCH 2/5] xfs: remove XFS_LI_RECOVERED Darrick J. Wong
  0 siblings, 1 reply; 24+ messages in thread
From: Darrick J. Wong @ 2020-10-05 18:19 UTC (permalink / raw)
  To: darrick.wong
  Cc: Christoph Hellwig, Brian Foster, Dave Chinner, linux-xfs, david,
	hch, bfoster

Hi all,

This series of log fixes dates back to an earlier discussion that Dave
and I had about the weird way that log recovery works w.r.t. intent
items.  The current code juggles nested transactions so that it can
siphon off new deferred items for later; this we replace with a new
dfops freezer that captures the log reservation type and remaining block
reservation so that we finish the new deferred items with the same
transaction context as we would have had the system not gone down.

v2: rework the defer capture api per hch suggestions
v3: rework the api again, per bfoster suggestions, so now
xfs_defer_capture is only responsible for creating the capture device,
and log recovery still has to do some work to commit a transaction and
free resources
v4: kill XFS_LI_RECOVERED and move all the defer capture commit and
release code to xfs_defer.c
v5: absorb remaining realtime reservation, only save transaction
reservation (and not logcount or flags)

If you're going to start using this mess, you probably ought to just
pull from my git trees, which are linked below.

This is an extraordinary way to destroy everything.  Enjoy!
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=fix-recovery-intent-chaining-5.10
---
 fs/xfs/libxfs/xfs_defer.c  |  120 ++++++++++++++++++++++++++++++++---------
 fs/xfs/libxfs/xfs_defer.h  |   26 +++++++++
 fs/xfs/xfs_bmap_item.c     |   16 +----
 fs/xfs/xfs_extfree_item.c  |    7 +-
 fs/xfs/xfs_log_recover.c   |  129 +++++++++++++++++++++++++-------------------
 fs/xfs/xfs_refcount_item.c |   16 +----
 fs/xfs/xfs_rmap_item.c     |    7 +-
 fs/xfs/xfs_trans.h         |    7 +-
 8 files changed, 208 insertions(+), 120 deletions(-)


^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2020-10-05 18:20 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-29 17:43 [PATCH v4 0/5] xfs: fix how we deal with new intents during recovery Darrick J. Wong
2020-09-29 17:43 ` [PATCH 1/5] xfs: remove xfs_defer_reset Darrick J. Wong
2020-10-01 17:30   ` Brian Foster
2020-09-29 17:43 ` [PATCH 2/5] xfs: remove XFS_LI_RECOVERED Darrick J. Wong
2020-10-01 17:30   ` Brian Foster
2020-10-02  7:16   ` Christoph Hellwig
2020-09-29 17:43 ` [PATCH 3/5] xfs: proper replay of deferred ops queued during log recovery Darrick J. Wong
2020-10-01 17:31   ` Brian Foster
2020-10-01 17:41     ` Darrick J. Wong
2020-10-02  7:18   ` Christoph Hellwig
2020-09-29 17:43 ` [PATCH 4/5] xfs: xfs_defer_capture should absorb remaining block reservation Darrick J. Wong
2020-10-01 17:32   ` Brian Foster
2020-10-01 17:46     ` Darrick J. Wong
2020-10-02  4:20   ` [PATCH v4.2 " Darrick J. Wong
2020-10-02  7:22     ` Christoph Hellwig
2020-10-02 10:39     ` Brian Foster
2020-09-29 17:43 ` [PATCH 5/5] xfs: xfs_defer_capture should absorb remaining transaction reservation Darrick J. Wong
2020-10-01 17:32   ` Brian Foster
2020-10-01 17:52     ` Darrick J. Wong
2020-10-02  4:21   ` [PATCH v4.2 " Darrick J. Wong
2020-10-02  7:24     ` Christoph Hellwig
2020-10-02  7:32       ` Christoph Hellwig
2020-10-02 10:39     ` Brian Foster
  -- strict thread matches above, loose matches on Subject: below --
2020-10-05 18:19 [PATCH v5 0/5] xfs: fix how we deal with new intents during recovery Darrick J. Wong
2020-10-05 18:20 ` [PATCH 2/5] xfs: remove XFS_LI_RECOVERED Darrick J. Wong

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox