uuid_mutex lock is not a per-fs lock but a global lock. The main aim of this patch-set is to critically review the usage of this lock, and delete the unnecessary once. By doing this we improve the concurrency of device operations across multiple btrfs filesystems is in the system.
patch 1: Was sent before, I am including it here, as its about uuid_mutex. patch 2-9: Are cleanup and or preparatory patches. patch 10-14: Drops the uuid_mutex and makes sure there is enough lock, as discussed in the patch change log. patch 15: A generic cleanup patch around functions in the same context. These patches are on top of https://github.com/kdave/btrfs-devel.git remove-volume-mutex And it will be a good idea to go along with the kill-volume-mutex patches. This is tested with xfstests and there are no _new_ regression. And I am trying to understand the old regressions, and notice that they are inconsistent. Anand Jain (15): btrfs: optimize move uuid_mutex closer to the critical section btrfs: rename struct btrfs_fs_devices::list btrfs: cleanup __btrfs_open_devices() drop head pointer btrfs: rename __btrfs_close_devices to close_fs_devices btrfs: rename __btrfs_open_devices to open_fs_devices btrfs: cleanup find_device() drop list_head pointer btrfs: cleanup btrfs_rm_device() promote fs_devices pointer btrfs: cleanup btrfs_rm_device() use cur_devices btrfs: uuid_mutex in read_chunk_tree, add a comment btrfs: drop uuid_mutex in btrfs_free_extra_devids() btrfs: drop uuid_mutex in btrfs_open_devices() btrfs: drop uuid_mutex in close_fs_devices() btrfs: drop uuid_mutex in btrfs_dev_replace_finishing() btrfs: drop uuid_mutex in btrfs_destroy_dev_replace_tgtdev() btrfs: cleanup btrfs_destroy_dev_replace_tgtdev() localize btrfs_fs_devices fs/btrfs/dev-replace.c | 3 -- fs/btrfs/sysfs.c | 2 +- fs/btrfs/volumes.c | 113 ++++++++++++++++++++++++------------------------- fs/btrfs/volumes.h | 2 +- 4 files changed, 58 insertions(+), 62 deletions(-) -- 2.7.0 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
