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/106300 /git.openstack. org/cgit/ openstack/ cinder/ commit/ ?id=c74efd7765e 33379c500563591 23eb6f00fedb07
Committed: https:/
Submitter: Jenkins
Branch: stable/icehouse
commit c74efd7765e3337 9c50056359123eb 6f00fedb07
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 8dbf1c7304b30e4 9f8e6a54ff)
Closes-Bug: #1317075
Related-Bug: #1270192
(cherry picked from commit da9597aed0186e6