[v5,0/5] xfs: fix how we deal with new intents during recovery

Message

Darrick J. Wong Oct. 5, 2020, 6:19 p.m. UTC

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(-)