Whamcloud - gitweb
b=21574 PING_INTERVAL_SHORT should not postpone the next ping
authorJohann Lombardi <johann@sun.com>
Sat, 16 Jan 2010 14:27:17 +0000 (15:27 +0100)
committerJohann Lombardi <johann@sun.com>
Sat, 16 Jan 2010 14:27:17 +0000 (15:27 +0100)
i=oleg
i=andrew

Most our tests run with obd_timeout=20s, so PING_INTERVAL=5s, while
PING_INTERVAL_SHORT=7s. ptlrpc_pinger_commit_expected() was actually
not intended to delay pings.
Although we would prefer to schedule the next ping after a
bit more than 5s (jbd commit time), using 5s instead of 7s
is not a big deal since we will have to only wait for 5
additional seconds in the worst case.

lustre/include/obd_support.h

index b7898cd..621282f 100644 (file)
@@ -88,7 +88,7 @@ extern unsigned int obd_alloc_fail_rate;
 /* Change recovery-small 26b time if you change this */
 #define PING_INTERVAL max(obd_timeout / 4, 1U)
 /* a bit more than maximal journal commit time in seconds */
-#define PING_INTERVAL_SHORT 7
+#define PING_INTERVAL_SHORT min(PING_INTERVAL, 7U)
 /* maximum server ping service time excluding network latency */
 #define PING_SVC_TIMEOUT 15
 /* Client may skip 1 ping; we must wait at least 2.5. But for multiple