When the VDOPOOL becomes full with current version of lvm2 - the only way to discover such state by user is to check for 100% data usage of VDOPOOL by lvs.

However this is not a good way to inform user about such highly problematic situation.

The associated problems are - the fullness might be a 'temporary' issue - so user might be even unaware the error state of full pool even occurred - it's not even reported by kvdo target - the only observable moment is report of 'dmeventd' monitoring and kernel write error message - which might be possibly hardly associated.

Some small example how to examine situation:

1. Create small VDO pool with 'overprovisioned' 200MiB volume
2. while the vdopool can only store <130MiB
   #
3. lvcreate --vdo -V200M -L2.9G --vdosettings 'vdoslabsizemb=128' -n lv vg

1. now start to write to such volume urandom data with 'dd'

1. dd if=/dev/urandom of=/dev/vg/lv bs=1M count=140 status=progress

Such operation for a user ends with 'success' return code 0.
Kernel reports in parallel some 'async' write errors in dmesg.

Situation gets better if the options 'conv=fdatasync' or 'oflag=direct' are used with dd so the userspace app at least recognizes an error on write.

Yet we still can easily 'miss' the error reporting state on lvm2 side - as even simple 'TRIM' on a device might make look such VDO LV looking normaly - although on overfilled pool the fsck operation shall be always used.

Enhance this use case - similarities could be probably found with thin-pool out-of-data_space/out_of_metadata_space