introduce lvm forcevg option to forcibly deactivate the whole vg
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 1 patch 0 repliesNew
Patches in v1 No applies recorded yet
The patch the cover letter announces is not in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Patch review 0/1] 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