Dne 10. 09. 19 v 17:20 David Teigland napsal(a):
_pvscan_aa
vgchange_activate
_activate_lvs_in_vg
sync_local_dev_names
fs_unlock
dm_udev_wait <=== this point!
```
Could you explain to us what's happening in this code? IIUC, an
incoming uevent triggers pvscan, which then possibly triggers VG
activation. That in turn would create more uevents. The pvscan process
then waits for uevents for the tree "root" of the activated LVs to be
processed.
Can't we move this waiting logic out of the uevent handling? It seems
weird to me that a process that acts on a uevent waits for the
completion of another, later uevent. This is almost guaranteed to cause
delays during "uevent storms". Is it really necessary?
Maybe we could create a separate service that would be responsible for
waiting for all these outstanding udev cookies?
Peter Rajnoha walked me through the details of this, and explained that a
timeout as you describe looks quite possible given default timeouts, and
that lvm doesn't really require that udev wait.
So, I pushed out this patch to allow pvscan with --noudevsync:
https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=3e5e7fd6c93517278b2451a08f47e16d052babbb
You'll want to add that option to lvm2-pvscan.service; we can hopefully
update the service to use that if things look good from testing.
This is certainly a bug.
lvm2 surely does need to communication with udev for any activation.
We can't let running activation 'on-the-fly' without control on system with
udev (so we do not issue 'remove' while there is still 'add' in progress)
Also any more complex target like thin-pool need to wait till metadata LV gets
ready for thin-check.
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
