Bug 1268445
| Summary: | limitations to what can be done to shared (-asy) activated LVs on shared VGs | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Corey Marthaler <cmarthal> | ||||
| Component: | lvm2 | Assignee: | David Teigland <teigland> | ||||
| lvm2 sub component: | LVM lock daemon / lvmlockd | QA Contact: | cluster-qe <cluster-qe> | ||||
| Status: | CLOSED WONTFIX | Docs Contact: | |||||
| Severity: | low | ||||||
| Priority: | low | CC: | agk, heinzm, jbrassow, prajnoha, teigland, zkabelac | ||||
| Version: | 7.2 | ||||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-12-15 07:37:14 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Corey Marthaler
2015-10-02 20:14:54 UTC
All error numbers from lvmlockd are meant to be caught so that an explanatory error message can be printed instead of just the error number, so this EEXIST error: LV vg/lv lock failed: error -17 has been updated and is now printed as: LV is already locked with incompatible mode: vg/lv Because the LV is active with a shared LV lock, but lvchange wants to use an incompatible ex LV lock to "modify" the LV. This may change since tags don't really modify the LV... The larger question above is whether tags can be added or removed on an LV that is active with a shared lock (potentially active on multiple hosts). Since adding and removing tags does not require the LV to be active, does not affect how the LV is used, but only changes VG metadata, we could just lock the VG for the metadata change, and not bother with any LV lock at all. A second issue above is what lvchange actions can be combined in a single command, e.g. -an and --addtag are done together. To answer this we'll want to look at all possible combinations of lvchange actions and decide on a common policy for what can be combined. Other issues: shared mirror conversion attempt [root@harding-02 ~]# lvconvert --type mirror -m 1 /dev/linear_5_1697/linear_5_16970 LV linear_5_1697/linear_5_16970 lock failed: error -17 shared size reduction attempt [root@mckinley-01 ~]# lvreduce -f -l 158 /dev/linear_1_9785/linear_1_97850 LV linear_1_9785/linear_1_97850 lock failed: error -17 [root@host-113 ~]# lvchange -f -My --major 255 --minor 139 /dev/stripe_2_4948/stripe_2_49480 LV stripe_2_4948/stripe_2_49480 lock failed: error -17 [root@harding-02 ~]# lvrename stripe_4_4693 /dev/stripe_4_4693/stripe_4_46930 rename_889 LV stripe_4_4693/stripe_4_46930 lock failed: error -17 Created attachment 1440715 [details]
verbose vgcreate attempt
Not sure this is even the same issue, but here's another "-17" issue recently seen
mckinley-01: pvcreate /dev/mapper/mpatha2 /dev/mapper/mpatha1 /dev/mapper/mpathb2 /dev/mapper/mpathb1 /dev/mapper/mpathc2 /dev/mapper/mpathc1 /dev/mapper/mpathd2 /dev/mapper/mpathd1 /dev/mapper/mpathe2 /dev/mapper/mpathe1
mckinley-01: vgcreate --shared raid_sanity /dev/mapper/mpatha2 /dev/mapper/mpatha1 /dev/mapper/mpathb2 /dev/mapper/mpathb1 /dev/mapper/mpathc2 /dev/mapper/mpathc1 /dev/mapper/mpathd2 /dev/mapper/mpathd1 /dev/mapper/mpathe2 /dev/mapper/mpathe1
VG raid_sanity init failed: -17
Failed to initialize lock args for lock type dlm
vgcreate failed on mckinley-01
Adding a note to this bug about shared lvextend bug 1649086 - Support online resizing for GFS2. Adding a note to this bug about shared lvconvert bug 1649546 - Support shared activated image conversion (this was already mentioned above in comment #2 w/ sanlock. Bug 1649546 being about w/ dlm) After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. |