A lvremove -f might leave behind suspended devices
when it is racing with udev or other processes
still accessing any of the device files. The previous
solution of using lvchange -an on the LV had the
side-effect of deactivating origin LVs alongway in
the thick volume case, which was undesired.
It turns out retrying the deactivation twice and
ignoring the suspended devices on the second iteration
avoids the hang of all LVM operations after an initial
failure.
Reviewed: https:/ /review. openstack. org/99784 /git.openstack. org/cgit/ openstack/ cinder/ commit/ ?id=da9597aed01 86e68dbf1c7304b 30e49f8e6a54ff
Committed: https:/
Submitter: Jenkins
Branch: master
commit da9597aed0186e6 8dbf1c7304b30e4 9f8e6a54ff
Author: Dirk Mueller <email address hidden>
Date: Fri Jun 13 00:24:23 2014 +0200
Retry lvremove with ignore_ suspended_ devices
A lvremove -f might leave behind suspended devices
when it is racing with udev or other processes
still accessing any of the device files. The previous
solution of using lvchange -an on the LV had the
side-effect of deactivating origin LVs alongway in
the thick volume case, which was undesired.
It turns out retrying the deactivation twice and
ignoring the suspended devices on the second iteration
avoids the hang of all LVM operations after an initial
failure.
Change-Id: I0d6fb74084d049 ea184e68f2dcc4e 74f400b7dbd
Closes-Bug: #1317075
Related-Bug: #1270192