[PATCH 0/3] xfs: fix how we deal with new intents during recovery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

This second 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.

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
---
 fs/xfs/libxfs/xfs_defer.c       |   66 ++++++++++++++++++++++---
 fs/xfs/libxfs/xfs_defer.h       |   22 ++++++++
 fs/xfs/libxfs/xfs_log_recover.h |    4 +
 fs/xfs/xfs_bmap_item.c          |   16 +-----
 fs/xfs/xfs_extfree_item.c       |    7 +--
 fs/xfs/xfs_log_recover.c        |  105 ++++++++++++++++++++++-----------------
 fs/xfs/xfs_refcount_item.c      |   16 +-----
 fs/xfs/xfs_rmap_item.c          |    7 +--
 fs/xfs/xfs_trans.h              |    4 +
 9 files changed, 160 insertions(+), 87 deletions(-)




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux