These locks seem to mostly point to instances of "lvs", "vgs", and "lvcreate" commands blocking against each other. These all lock LVM VG metadata while running.
Part of the length of time is these block indicates that something is probably wrong and needs further investigation. (I suspect they are maybe scanning some dead devices, etc.)
But, this leads me back to a previous suggestion: it's possible that enabling lvmetad on these gate machines could alleviate this issue. It caches some of the information collected during scans and so may help avoid this by having fewer long-running commands.
I made this patch to try to troubleshoot this: https:/ /review. openstack. org/#/c/ 130364/
Ignoring the errors because I didn't use root_helper, there is a pattern here: logs.openstack. org/64/ 130364/ 1/check/ check-tempest- dsvm-full/ caf173e/ logs/screen- c-vol.txt. gz#_2014- 10-22_21_ 48_07_126
http://
These locks seem to mostly point to instances of "lvs", "vgs", and "lvcreate" commands blocking against each other. These all lock LVM VG metadata while running.
Part of the length of time is these block indicates that something is probably wrong and needs further investigation. (I suspect they are maybe scanning some dead devices, etc.)
But, this leads me back to a previous suggestion: it's possible that enabling lvmetad on these gate machines could alleviate this issue. It caches some of the information collected during scans and so may help avoid this by having fewer long-running commands.