Hi all, Now that we've ported support for in-memory btrees to userspace, port xfs_repair to use them instead of the clunky slab interface that we currently use. This has the effect of moving memory consumption for tracking reverse mappings into a memfd file, which means that we could (theoretically) reduce the memory requirements by pointing it at an on-disk file or something. It also enables us to remove the sorting step and to avoid having to coalesce adjacent contiguous bmap records into a single rmap record. If you're going to start using this code, I strongly recommend pulling from my git trees, which are linked below. This has been running on the djcloud for months with no problems. Enjoy! Comments and questions are, as always, welcome. xfsprogs git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=repair-use-in-memory-btrees-6.9 --- Commits in this patchset: * libxfs: provide a kernel-compatible kasprintf * xfs_repair: convert regular rmap repair to use in-memory btrees * xfs_repair: verify on-disk rmap btrees with in-memory btree data * xfs_repair: compute refcount data from in-memory rmap btrees * xfs_repair: reduce rmap bag memory usage when creating refcounts * xfs_repair: remove the old rmap collection slabs --- include/kmem.h | 3 include/libxfs.h | 3 libxfs/buf_mem.h | 5 libxfs/kmem.c | 13 + libxfs/libxfs_api_defs.h | 13 + repair/agbtree.c | 18 + repair/agbtree.h | 1 repair/dinode.c | 9 - repair/phase4.c | 25 -- repair/phase5.c | 2 repair/rmap.c | 762 ++++++++++++++++++++++++++++++---------------- repair/rmap.h | 25 +- repair/scan.c | 7 repair/slab.c | 49 ++- repair/slab.h | 2 repair/xfs_repair.c | 6 16 files changed, 602 insertions(+), 341 deletions(-)
