[PATCH 1/1] dm-multipath: delay retry of bypassed pg

[PATCH 1/1] dm-multipath: delay retry of bypassed pg

[michaelc]

From: Mike Christie <michaelc@cs.wisc.edu>

If there are only bypassed PGs available then we do not want
to retry right away. If for example the controller was getting
reset or there was a fw upgrade going on and that was the reason
for the bypass, then retrying right away is going to cause a flood of
log messages and retries for what could be a longish time (more than
a couple seconds and possible up to several minutes).

For the case where the only PGs are ones that are bypassed this
patch will have dm-multipath delay the pg init by setting the
pg_init_delay_retry flag.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
---
 drivers/md/dm-mpath.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
index 801d92d..65e0d26 100644
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -307,14 +307,18 @@ static void __choose_pgpath(struct multipath *m, size_t nr_bytes)
 	/*
 	 * Loop through priority groups until we find a valid path.
 	 * First time we skip PGs marked 'bypassed'.
-	 * Second time we only try the ones we skipped.
+	 * Second time we only try the ones we skipped, but will set
+	 * pg_init_delay_retry so we do not hammer controllers.
 	 */
 	do {
 		list_for_each_entry(pg, &m->priority_groups, list) {
 			if (pg->bypassed == bypassed)
 				continue;
-			if (!__choose_path_in_pg(m, pg, nr_bytes))
+			if (!__choose_path_in_pg(m, pg, nr_bytes)) {
+				if (!bypassed)
+					m->pg_init_delay_retry = 1;
 				return;
+			}
 		}
 	} while (bypassed--);
 
-- 
1.7.7.6

Re: [PATCH 1/1] dm-multipath: delay retry of bypassed pg

[Mike Snitzer]

On Tue, Apr 17 2012 at  1:46am -0400,
michaelc@cs.wisc.edu <michaelc@cs.wisc.edu> wrote:

> From: Mike Christie <michaelc@cs.wisc.edu>
> 
> If there are only bypassed PGs available then we do not want
> to retry right away. If for example the controller was getting
> reset or there was a fw upgrade going on and that was the reason
> for the bypass, then retrying right away is going to cause a flood of
> log messages and retries for what could be a longish time (more than
> a couple seconds and possible up to several minutes).
> 
> For the case where the only PGs are ones that are bypassed this
> patch will have dm-multipath delay the pg init by setting the
> pg_init_delay_retry flag.
> 
> Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>

Acked-by: Mike Snitzer <snitzer@redhat.com>