Hi all, As Dave Chinner has complained about on IRC, there are a couple of things about reflink that are very inefficient. First of all, we limited the size of all bunmapi operations to avoid flooding the log with defer ops in the worst case, but recent changes to the defer ops code have solved that problem, so get rid of the bunmapi length clamp. Second, the log reservations for reflink operations are far far larger than they need to be. Shrink them to exactly what we need to handle each deferred RUI and CUI log item, and no more. Also reduce logcount because we don't need 8 rolls per operation. Introduce a transaction reservation compatibility layer to avoid changing the minimum log size calculations. 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=reflink-speedups-5.19 --- fs/xfs/libxfs/xfs_bmap.c | 22 ----- fs/xfs/libxfs/xfs_log_rlimit.c | 17 +++- fs/xfs/libxfs/xfs_refcount.c | 14 ++- fs/xfs/libxfs/xfs_refcount.h | 8 -- fs/xfs/libxfs/xfs_trans_resv.c | 193 +++++++++++++++++++++++++++++++++------- fs/xfs/libxfs/xfs_trans_resv.h | 8 +- fs/xfs/xfs_reflink.c | 95 ++++++++++++-------- fs/xfs/xfs_trace.h | 15 ++- 8 files changed, 264 insertions(+), 108 deletions(-)