mirror of
git://sourceware.org/git/lvm2.git
synced 2025-03-09 12:58:41 +03:00
ca51435153
When images and their associated metadata are removed from a RAID1 LV, the remaining sub-LVs are "shifted" down to fill the gaps. For example, if there is a 3-way mirror: [0][1][2] and we remove device#0, the devices will be shifted down [1][2] and renamed. [0][1] This can create a problem for resume_lv (specifically, dm_tree_activate_children) during the renaming process though. This is because it will attempt to rename the higher indexed sub-LVs first and find that it cannot because there are currently other sub-LVs with that name. The solution is to check for a conflicting name before attempting to rename. If a conflict is found and that conflicting sub-LV is also in the process of renaming, we can defer the current rename until the conflicting sub-LV has renamed and cleared the conflict. Now that resume_lv can handle these types of rename conflicts, we can remove the workaround in RAID that was attempting to resume a RAID1 LV from the bottom-up in order to force a proper rename in assending order before attempting a resume on the top-level LV. This "hack" only worked for single machine use-cases of LVM. Clearing this up paves the way for exclusive activation of RAID LVs in a cluster.