introduce lvm forcevg option to forcibly deactivate the whole vg
cover introduce lvm forcevg option to forcibly deactivate the whole vg
Hi all,
commit 92ded9af9809dd0f4233bacaafab3e7942a6afff
Author: Huan Zhang <[email protected]> Date: Thu Sep 14 15:25:05 2017 +0800
introduce lvm forcevg option to forcibly deactivate the whole vg
the primary job of this option is to flush in-flight io and replace the lv dm table with 'error' target(using dmsetup wipe_table) as soon as possible. so it will not deactivate holders and not try to lvchange first before wipe_table. it's supposed to be used in 'lvmlockctl --kill vgname' to force deactivate vg and drop locks before sanlock watchdog reset host.
man/blkdeactivate.8_main +15 -0
@@ -50,6 +50,15 @@ Retry removal several times in case of failure. Deactivate the whole LVM Volume Group when processing a Logical Volume. Deactivating the Volume Group as a whole is quicker than deactivating each Logical Volume separately. +.IP \fIforcevg\fP +Forcibly deactivate the whole LVM Volume Group as soon as possible. +The primary job of this option is to flush the in-flight io and +then replace the lv dm table with 'error' target. (using dmsetup +wipe_table). After that, it's safe to do drop locks. +Disablequeueing if lv setup on multipath device. +This option is usually used in sanlock('lvmlockctl --kill') +fence procedure to avoid host reset. +Any other options(e.g. -d retry|force, -u) will be ignored. .RE .TP .BR -m ", " --mpathoption \ \fImpath_options\fP
@@ -99,6 +108,12 @@ Volume Group at once when processing an LVM Logical Volume. .B blkdeactivate -u -d retry -l wholevg .BR .P +Force deactivate the whole vg. +.BR +# +.B blkdeactivate -l forcevg testvg +.BR +.P Deactivate all supported block devices found in the system. If the deactivation of a device-mapper device fails, retry it and force removal. .BR
scripts/blkdeactivate.sh.in +100 -8
145 lines not on this page · raw message
cover introduce lvm forcevg option to forcibly deactivate the whole vg
Dne 14.9.2017 v 09:37 Zhang Huan napsal(a):
Quoted 8 lines
Hi all,
commit
92ded9af9809dd0f4233bacaafab3e7942a6afffAuthor: Huan Zhang <[email protected]> Date: Thu Sep 14 15:25:05 2017 +0800introduce lvm forcevg option to forcibly deactivate the whole vg
Hi
Coincidentally - I've just opened this BZ today:
https://bugzilla.redhat.com/show_bug.cgi?id=1491609
Mostly likely this BZ can be extended to also support forcible table remove for 'vg/lvchange' command.
The solution presented in this patch can interfere with lvm2 commands so I'd be worrying about data correctness.
Regards
Zdenek
cover introduce lvm forcevg option to forcibly deactivate the whole vg
Quoted 9 lines · Zdenek Kabelac
Dne 14.9.2017 v 09:37 Zhang Huan napsal(a):
Quoted 7 lines
Hi all,
commit
92ded9af9809dd0f4233bacaafab3e7942a6afffAuthor: Huan Zhang <[email protected]> Date: Thu Sep 14 15:25:05 2017 +0800introduce lvm forcevg option to forcibly deactivate the whole vg
Quoted 8 lines
Hi
Coincidentally - I've just opened this BZ today:
https://bugzilla.redhat.com/show_bug.cgi?id=1491609
Mostly likely this BZ can be extended to also support forcible table remove for 'vg/lvchange' command.
Using an lvm command is a problem for us here because it will read devices and may likely get stuck, blocking the script which only has about 40 seconds to finish in our case. And this is run precisely because i/o to a device is not working.
Quoted 2 lines
The solution presented in this patch can interfere with lvm2 commands so I'd be worrying about data correctness.
Our particular use of this is as a helper script that sanlock runs when the device holding the leases goes away, and the machine will be imminently reset by the watchdog if we can't disable the LVs. Given those unique circumstances, we don't care about other lvm commands. Is this case is so specialized that it should be put in a separate script rather than in blkdeactivate?
This is also described in the section "sanlock lease storage failure" in
http://man7.org/linux/man-pages/man8/lvmlockd.8.html
cover introduce lvm forcevg option to forcibly deactivate the whole vg
Dne 14.9.2017 v 20:39 David Teigland napsal(a):
Quoted 16 lines · Zdenek Kabelac
Quoted 15 lines
Dne 14.9.2017 v 09:37 Zhang Huan napsal(a):
Quoted 7 lines
Hi all,
commit
92ded9af9809dd0f4233bacaafab3e7942a6afffAuthor: Huan Zhang <[email protected]> Date: Thu Sep 14 15:25:05 2017 +0800introduce lvm forcevg option to forcibly deactivate the whole vg
Hi
Coincidentally - I've just opened this BZ today:
Quoted 7 lines
Quoted 2 lines
Mostly likely this BZ can be extended to also support forcible table remove for 'vg/lvchange' command.
Using an lvm command is a problem for us here because it will read devices and may likely get stuck, blocking the script which only has about 40 seconds to finish in our case. And this is run precisely because i/o to a device is not working.
Hmm - but script seems to be calling apps like umount - that isn't going cause issues ?
Shouldn't be umount switched to the 'lazy' variant then ?
Quoted 8 lines
Quoted 2 lines
The solution presented in this patch can interfere with lvm2 commands so I'd be worrying about data correctness >
Our particular use of this is as a helper script that sanlock runs when the device holding the leases goes away, and the machine will be imminently reset by the watchdog if we can't disable the LVs. Given those unique circumstances, we don't care about other lvm commands. Is this case is so specialized that it should be put in a separate script rather than in blkdeactivate?
Wondering if there could be something for sharing for possibly usage in cases user wants to drop devices when thin-pool gets 'too full' and devices should be forcibly dropped even when they are in use...
Zdenek
cover introduce lvm forcevg option to forcibly deactivate the whole vg
Quoted 2 lines
Hmm - but script seems to be calling apps like umount - that isn't going cause issues ?
forcevg is not doing unmount because it would have problems (and we wouldn't want to modify the system's filesystem namespace.)
Quoted 10 lines
Quoted 6 lines
Our particular use of this is as a helper script that sanlock runs when the device holding the leases goes away, and the machine will be imminently reset by the watchdog if we can't disable the LVs. Given those unique circumstances, we don't care about other lvm commands. Is this case is so specialized that it should be put in a separate script rather than in blkdeactivate?
Wondering if there could be something for sharing for possibly usage in cases user wants to drop devices when thin-pool gets 'too full' and devices should be forcibly dropped even when they are in use...
That would be nice, if it could accomodate the unusual sanlock helper requirements.
cover introduce lvm forcevg option to forcibly deactivate the whole vg
In reply to Zhang HuanHi Zhang,
I discussed this with Alasdair who had the good idea that we could do this with just a couple of dmsetup commands, e.g.
dmsetup info -c -S "uuid=~LVM && vgname=$VG && lv_layer=\"\"" -o name --noheadings | xargs dmsetup wipe_table
If this works, I think it would be a nicer solution than going through the blkdeactivate script.
Dave