Hide Forgot
+++ This bug was initially created as a clone of Bug #1410768 +++ When 'dmeventd' plugin calls 'lvconvert' it provides implicit and unconfigurable reaction when called command fails. i.e. in case of thin-pool failing resize, it will try to umount unconditionally all thin volumes associated with such thin pool when compile-time defined threshold (>95%) is reached. This reaction is not likely wanted for newer kernels and there are users wishing to operate full thin-pool without umount disruption. As 'dmeventd' has no configuration, we need to provide some policy configurable knobs for lvm2 command (sacrificing some potential error handling paths). We decided to allow the whole command to be configurable in lvm.conf as follows: dmeventd { thin_command = "lvm lvextend --use-policies" } The plugin runs the command with each 5% increment when thin-pool data volume or metadata volume gets above 50% full. A command that starts with the prefix 'lvm ' is a built-in lvm command. A command that starts with '/' can be the full path to an external command or script of your own.
As this BZ present important change/improvement in thin-pool behavior worth a doc text - cloned into 7.4
Need clear description for slevine (in doc_text box)
This went into the code base back in January via upstream bug 1410768 to offer an alternative for those people for whom the automatic umount was a problem. commit 85dab3963fbf8b3cc1be84f2d7c43257075ac2a3 Author: Zdenek Kabelac <zkabelac> Date: Fri Jan 20 22:54:20 2017 +0100 dmeventd_thin: enable support for external command https://www.redhat.com/archives/lvm-devel/2017-January/msg00036.html commit 04a9cad499848cfc025d33ca28e9f657abc80ca3 Author: Zdenek Kabelac <zkabelac> Date: Wed Jan 18 09:54:32 2017 +0100 config: new option dmeventd/thin_command This setting will allowing configuring which command gets executed when thin-pool fullness goes from 50%..100% https://www.redhat.com/archives/lvm-devel/2017-January/msg00024.html
Here is the part of lvm2 test suite script creating 'auto-umounting' behavior via execution of the external shell script: --- #!/bin/sh echo "Data: \$DMEVENTD_THIN_POOL_DATA" echo "Metadata: \$DMEVENTD_THIN_POOL_METADATA" $TESTDIR/lib/lvextend --use-policies \$1 || { umount "$mntdir" || true umount "$mntusedir" || true return 0 } test \$($TESTDIR/lib/lvs -o selected -S "data_percent>95||metadata_percent>95" --noheadings \$1) -eq 0 || { umount "$mntdir" || true umount "$mntusedir" || true return 0 } --- (part of lvm2/test/shell/thin-autoumount-dmeventd.sh) https://sourceware.org/git/?p=lvm2.git;a=blob;f=test/shell/thin-autoumount-dmeventd.sh;h=5e1c2be8abdb632ad8573b9094d1a0dc49fc6f51;hb=HEAD So what the code does today (as documented in 'man dmeventd' thin plugin behavior) - it no longer umounts anything - as this appeared to be causing some other possibly very serious troubles like write to a completely different storage after umount. To 'mimic' the old logic (if needed) - user has to use the similar script like the one pasted here. You can see here how the ENV vars are set and usable without the need to call 'lvs' inside the script for simple decisions (i.e. calling fstrim ??) In general - if the script is NOT configured - lvm2 should just try to 'lvextend'. If the script IS configured - it's all in hands of script - executions of commands within such script should not cause dmeventd deadlock - running in the special mode. There is clearly a limitation of such script usage - if user would run the script from the same volume which is undergoing maintenance - possibly very bad things may happen.
Verified that if set, lvm will continue to call the external script defined in dmeventd { thin_command } as the thin_pool_autoextend_threshold is passed. 3.10.0-685.el7.x86_64 lvm2-2.02.171-7.el7 BUILT: Thu Jun 22 08:35:15 CDT 2017 lvm2-libs-2.02.171-7.el7 BUILT: Thu Jun 22 08:35:15 CDT 2017 lvm2-cluster-2.02.171-7.el7 BUILT: Thu Jun 22 08:35:15 CDT 2017 device-mapper-1.02.140-7.el7 BUILT: Thu Jun 22 08:35:15 CDT 2017 device-mapper-libs-1.02.140-7.el7 BUILT: Thu Jun 22 08:35:15 CDT 2017 device-mapper-event-1.02.140-7.el7 BUILT: Thu Jun 22 08:35:15 CDT 2017 device-mapper-event-libs-1.02.140-7.el7 BUILT: Thu Jun 22 08:35:15 CDT 2017 device-mapper-persistent-data-0.7.0-0.1.rc6.el7 BUILT: Mon Mar 27 10:15:46 CDT 2017
Zdenek, Jonathan: I tried to simplify/summarize this feature in the doc text for the release notes, but this seriously needs a technical review to be sure this conveys the defined behavior. The release notes don't really seem to be the place for documenting how to write an external script -- I don't know if that's a kBase article or an addition to the manual, but do you think we need to write that up?
There could be some more things added. On default - lvm2 calls 'internal' 'lvresize' as plugin - which does resize according to configuration (threshold values) User may 'opt-out' and use his own plugin/script which is called at same points. Advantage is - such plugin may do far more - it may call i.e. 'fstrim' earlier, it may try to drop unused thinLV (i.e. some old snapshots) to release some space in thin-pool and if that's still not enough it make call lvresize command. The main change is then - that current 'default' internal command is not doing any umounting - if user still finds such thing as usable - he needs to write his own plugin emulating this logic (we may possibly extend) dmeventd man page with some simple example if that's becomes wanted info.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2222