The series peels off the custom locking that's used for dev-replace and uses read-write semaphore in the end.
I've mainly focused on correctness and haven't measured the performance effects. There should be none as the blocking and waiting was merely open coding what the rw semaphore does, but without the fairness. The overall number of locks taken is low, there's a lots of IO in between so even if new scheme is slower, I don't expect any dramatic change. git://github.com/kdave/btrfs-devel.git dev/dev-replace-locking David Sterba (11): btrfs: remove btrfs_dev_replace::read_locks btrfs: open code btrfs_dev_replace_clear_lock_blocking btrfs: open code btrfs_dev_replace_stats_inc btrfs: open code btrfs_after_dev_replace_commit btrfs: dev-replace: avoid useless lock on error handling path btrfs: dev-replace: move replace members out of fs_info btrfs: dev-replace: remove pointless assert in write unlock btrfs: reada: reorder dev-replace locks before radix tree preload btrfs: dev-replace: swich locking to rw semaphore btrfs: dev-replace: remove custom read/write blocking scheme btrfs: dev-replace: open code trivial locking helpers fs/btrfs/ctree.h | 11 ++-- fs/btrfs/dev-replace.c | 136 ++++++++++++----------------------------- fs/btrfs/dev-replace.h | 13 ---- fs/btrfs/disk-io.c | 14 ++--- fs/btrfs/reada.c | 16 ++--- fs/btrfs/scrub.c | 26 ++++---- fs/btrfs/transaction.c | 5 +- fs/btrfs/volumes.c | 23 ++++--- 8 files changed, 87 insertions(+), 157 deletions(-) -- 2.18.0
