Thanks for writing this.
+ * - fs_devices::device_list_mutex (per-fs, with RCU) + * + * protects updates to fs_devices::devices, ie. adding and deleting + * + * simple list traversal with read-only actions can be done with RCU + * protection + * + * may be used to exclude some operations from running concurrently without + * any modifications to the list (see write_all_supers)
+ * - volume_mutex + * + * coarse lock owned by a mounted filesystem; used to exclude some operations + * that cannot run in parallel and affect the higher-level properties of the + * filesystem like: device add/deleting/resize/replace, or balance
+ * - chunk_mutex + * + * protects chunks, adding or removing during allocation, trim or when + * a new device is added/removed
::
+ * Lock nesting + * ------------ + * + * uuid_mutex + * volume_mutex + * device_list_mutex + * chunk_mutex + * balance_mutex
If we have a list of operations that would consume these locks then we can map it accordingly for better clarity.
To me it looks like we have too many locks. - we don't have to differentiate the mounted and unmounted context for device locks. - Two lock would be sufficient, one for the device list (add/rm,replace,..) and another for device property changes (resize, trim,..). Thanks, Anand -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
