[linux-lvm] lvm+ sanlock snapshot issue
Andrea Leofreddi
a.leofreddi at vleo.net
Sat Mar 7 13:26:32 UTC 2020
Hello,
I'm running into an unexpected behaviour on lvm and sanlock: if I create a snapshot on an inactive logical volume the operation succeeds but the origin lv gets locked (while reported as inactive by lvm).
I get the same result both with the stock lvm from Ubuntu 18 and the latest master version from https://github.com/lvmteam/lvm2.git. Follows the procedure to reproduce the issue:
1. Setup a shared volume group vg01 and some (inactive) logical volumes as follow:
```
root at lvm2:~# lvs -o +lv_uuid
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert LV UUID
lv vg01 -wi------- 12.00m YzSN30-OE1O-TMqI-ali5-gm1x-Ws8J-Re1bFR
lv2 vg01 -wi------- 12.00m FoNx4D-jbOO-HRl7-OJNT-AtQi-d4Cw-lHLG5S
```
Lvmlockctl consistently reports both lv and lv2 as unlocked:
```
root at lvm2:~# lvmlockctl -i
VG vg01 lock_type=sanlock Dhth4G-Fool-tugB-hcjK-ZAL4-cXnM-Q3A4x0
LS sanlock lvm_vg01
LK VG un ver 29
LK GL un ver 0
LK LV un FoNx4D-jbOO-HRl7-OJNT-AtQi-d4Cw-lHLG5S
LK LV un YzSN30-OE1O-TMqI-ali5-gm1x-Ws8J-Re1bFR
```
2. Then create a snapshot of lv2:
```
root at lvm2:~/lvm2# lvcreate -L 12m -s lv2 -n vg01/lv2-snap
Logical volume "lv2-snap" created.
```
Lvm still thinks lv2 is inactive
```
root at lvm2:~/lvm2# lvs -o +lv_uuid
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert LV UUID
lv vg01 -wi------- 12.00m YzSN30-OE1O-TMqI-ali5-gm1x-Ws8J-Re1bFR
lv2 vg01 owi---s--- 12.00m FoNx4D-jbOO-HRl7-OJNT-AtQi-d4Cw-lHLG5S
lv2-snap vg01 swi---s--- 12.00m lv2 Tu3XQP-Bkcu-cQP5-XWY3-7CMc-9Fqa-b0y2m0
```
However `lv2` is still locked for lvmlockctl:
```
root at lvm2:~/lvm2# lvmlockctl -i
VG vg01 lock_type=sanlock Dhth4G-Fool-tugB-hcjK-ZAL4-cXnM-Q3A4x0
LS sanlock lvm_vg01
LK VG un ver 31
LK GL un ver 0
LK LV ex FoNx4D-jbOO-HRl7-OJNT-AtQi-d4Cw-lHLG5S <== locked
LK LV un YzSN30-OE1O-TMqI-ali5-gm1x-Ws8J-Re1bFR
```
Trying to activate lv2 on another host will fail; issuing `lvchange -a n lv2` from the locking host will fix it.
Looking a bit deeper in lvcreate, it seems that the leaked lock happens at `metadata/lv_manip.c:8082`:
```
#0 lockd_lv_name (cmd=0x555555c5f3b0, vg=0x5555564aa110, lv_name=0x5555564aa6d0 "lv2", lv_id=0x5555564aa5b0, lock_args=0x5555564aa6d8 "1.0.0:71303168",
def_mode=0x555555787fb1 "ex", flags=2) at locking/lvmlockd.c:2195
#1 0x00005555556cab0c in lockd_lv (cmd=0x555555c5f3b0, lv=0x5555564aa590, def_mode=0x555555787fb1 "ex", flags=2) at locking/lvmlockd.c:2387
#2 0x00005555556cb6f2 in lockd_init_lv (cmd=0x555555c5f3b0, vg=0x5555564aa110, lv=0x5555564aaf98, lp=0x7fffffffe250) at locking/lvmlockd.c:2682
#3 0x000055555565aabe in _lv_create_an_lv (vg=0x5555564aa110, lp=0x7fffffffe250, new_lv_name=0x7fffffffe82e "lv2-snap") at metadata/lv_manip.c:8082
#4 0x000055555565c743 in lv_create_single (vg=0x5555564aa110, lp=0x7fffffffe250) at metadata/lv_manip.c:8496
#5 0x00005555555ab271 in _lvcreate_single (cmd=0x555555c5f3b0, vg_name=0x555555c97318 "vg01", vg=0x5555564aa110, handle=0x555555c96f00) at lvcreate.c:1737
```
Any idea what's going on?
Kind regards,
Andrea Leofreddi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20200307/c1fae1ea/attachment.sig>
More information about the linux-lvm
mailing list