Description of problem: 'Attr' property of internal LVs is not being updated. For example for newly created raid LVs first attribute is "I" and its never updated to "i". DBUS: # busctl get-property com.redhat.lvmdbus1 /com/redhat/lvmdbus1/HiddenLv/0 com.redhat.lvmdbus1.LvCommon Name s "[lvol0_rimage_0]" # busctl get-property com.redhat.lvmdbus1 /com/redhat/lvmdbus1/HiddenLv/0 com.redhat.lvmdbus1.LvCommon Attr s "Iwi-aor---" LVS: # lvs -a LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lvol0 test rwi-a-r--- 504.00m 100.00 [lvol0_rimage_0] test iwi-aor--- 504.00m [lvol0_rimage_1] test iwi-aor--- 504.00m [lvol0_rmeta_0] test ewi-aor--- 4.00m [lvol0_rmeta_1] test ewi-aor--- 4.00m Version-Release number of selected component (if applicable): LVM version: 2.02.180(2) (2018-07-19) Library version: 1.02.149 (2018-07-19) Driver version: 4.39.0
lvmdbusd keeps its own cache, and it is invalid. Peter, I guess in this case no udev event is generated, right? What shall we do? 1. Always query lvm about the attributes, 2. Not sure that is a viable option, but could we generate a "notification" event even for changes, which do not require rescan, but are useful for client. 2.1 RAID/Mirror sync complete 2.2 Thin-pool data/meta over threshold ... 3. Do we have any other options?
lvmdbusd updates it's internal state when lvm tells it to. Forcing lvmdbusd to query lvm for every attribute access would make the service unusable as the number of internal cache updates would equal the number of dbus objects * the number of attributes on each object. This would happen on a GetManagedObjects call for example. IMHO the best way to handle this is to identify those code paths in lvm which are changing the visible state is to call the existing "ExternalEvent" on lvmdbusd as is already being done when things like pvcreate, vgcreate, lvcreate etc. are being done.
Thanks Tony, that's a corner of lvmdbusd I have not wandered to yet. However, I am not sure lvm is notified when RAID resync is finished...
Tony and I worked out a likely solution for this. When dmeventd gets a raid sync event, it should run 'vgscan --notifydbus'. This will cause lvmdbusd to update its state. To avoid running vgscan from dmeventd when it's not needed, dmeventd can check whether lvmdbusd is running (e.g. stat its pid file). If lvmdbusd is not running, then dmeventd can skip the vgscan command.
Shall we rate limit the event somehow? For example in case of writemostly + writebehind leg, it may be triggered a lot... Also there are more fields which would need updating: - data_percent - snap_percent - metadata_percent - copy_percent - sync_percent ...and these are changing a lot, so an event to rescan everything may not be the best option. I wonder, if we cannot get at least somewhat accurate values, how useful it is to have these values at all? IMO we should implement some of force rescan, periodic rescan, pull, and push: - force rescan method - refresh whole cache on demand (implemented but not exposed IIUC,) - periodic rescan method (start a lvmdbusd job) - to get at least somewhat relevant values, - pull - query a device for immediate value(s), - push - register with dmeventd to notify daemon about selected changes. Push would be useful for adjustable watermarks, crossing which should raise an event. For example: - data_percent under low(=70%) is green, under high(=90%) orange, over high red, and every critical(=1%) over high should raise an event. - for sync_percent, it should be possible to register a one-off event to trigger, after sync is complete, and similarly to trigger once after a sync drops under some level (=something is wrong.)