[lvm-devel] master - revert: restore original timeout

[Zdenek Kabelac]

Gitweb:        http://git.fedorahosted.org/git/?p=lvm2.git;a=commitdiff;h=2adaef82722ec71620a6d02c6c973d3472d705ae
Commit:        2adaef82722ec71620a6d02c6c973d3472d705ae
Parent:        171a668e81d9c647677465f042775722a35c5a6e
Author:        Zdenek Kabelac <zkabelac at redhat.com>
AuthorDate:    Wed May 28 15:27:14 2014 +0200
Committer:     Zdenek Kabelac <zkabelac at redhat.com>
CommitterDate: Wed May 28 15:33:41 2014 +0200

revert: restore original timeout

Accidently it's been commited - but it has also shown,
that on heavy loaded systems (like our test machine could be)
slightly bigger timeouts which waits longer for udev rules
processing does help and avoids occasional refuse of deactivation
because device is still being open.
(i.e. lvcreate...; lvchange -an...)

Unsure how we could now synchronize for this. On very slow(/loaded)
system 5 second timeout is simply not enough.

TODO: introduce at least lvm.conf configurable setting to
allow longer 'retry' loops.
---
 lib/activate/activate.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/activate/activate.c b/lib/activate/activate.c
index 7ad3654..41d74c7 100644
--- a/lib/activate/activate.c
+++ b/lib/activate/activate.c
@@ -726,7 +726,7 @@ int lv_check_not_in_use(struct cmd_context *cmd, struct logical_volume *lv,
 			return 0;
 		}
 
-		usleep(OPEN_COUNT_CHECK_USLEEP_DELAY * 4);
+		usleep(OPEN_COUNT_CHECK_USLEEP_DELAY);
 		log_debug_activation("Retrying open_count check for %s/%s.",
 				     lv->vg->name, lv->name);
 		if (!lv_info(cmd, lv, 0, info, 1, 0)) {