Description of problem: 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 a somewhat sacrifice certain 'error paths' in commands as unhandled. As a simple mechanism it seems to come in mind simple setting: thin_pool_lazy_umount_threshold = 100 (meaning do NOTHING) values in range: <thin_pool_autoextend_threshold, 100) will cause call of umount in case autoextend has failed. Version-Release number of selected component (if applicable): 2.02.169 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Maybe we go with 'more' generic logic: thin_pool_fail_autoextend_threshold = XXX thin_pool_fail_autoextend_command = [ ""..... ] which will call some preconfigured 'command' when configured 'threshold' passed with the last passed argument being thin-pool vgname/lvname (or maybe user can use user %thinpool in arglist....) Add more....
It seems we should try to let whole 'command' for extend to be fully configure - so i.e. plugin for thin-pool dmeventd gets this new field: dmeventd { thin_pool_command = [ ] } Defaulting to existing 'lvextend --use-policies....' (with dropped umount at dmeventd plugin part) This let user to gain full configuration for any percentage value of thin-pool from range of 50%, 55,...100% and appropriate reaction. Otherwise we would facing non-trivial troubles to solve with VG locking. This way user may plug-in just place-in any shell script and do query and change VG or any LV as need - even far before failure (i.e. dropping some unneeded thin LVs at some 'fullness' level. In general we would support much wider range or policies. The 'easiest' looks like passing in command with new API functions: dm_event_handler_set_command dm_event_handler_get_command We may also convert other plugins (mirror, raid, snapshot...)
So the API of dmeventd is not good for this, it's not extensible unless major rework would be made. So the new plan is to introduce 'smarter' command - plugin will use this command which then according to lvm.conf will run the configured action (i.e. old lvextend or some new script...)
So this is now resolved upstream and the behavior is documented in 'dmeventd' man page for thin plugin which needs to be checked for full description. We have either internal or external command lvm <- internal command (which no longer umounts volumes on error) /fullpath <- external command In the future we may add systemd service usage for this to avoid dmeventd forking.