On Tue, 2019-08-27 at 19:57 +0000, Martin Wilck wrote: > On Tue, 2019-08-27 at 12:28 +0000, Chongyun Wu wrote: > > Hi Martin and Ben, > > > > Cloud you help to view below patch, thanks. > > > > From a7126e33e7eff8a985600b41b1723ee66b183586 Mon Sep 17 00:00:00 > > 2001 > > From: Chongyun Wu <wu.chongyun@xxxxxxx> > > Date: Tue, 27 Aug 2019 10:23:50 +0800 > > Subject: [PATCH] multipathd: "san_path_err" failure optimization > > > > Let san_path_err_recovery_time path unstable can be > > detected and not reinstate it until this path keep up in > > san_path_err_recovery_time. It will fix heavy IO delay > > caused by parts of paths state shaky in multipath device. > > > > Test and result: > > Run up eth1 30s and down eth1 30s with 100 loops script to > > make some paths shaky in each multipath devices. > > Using below multipath.conf configure in defaults section: > > san_path_err_recovery_time 30 > > san_path_err_threshold 2 > > san_path_err_forget_rate 6 > > After test, not found any IO delay logs except several logs in the > > very > > beginning which before san_path_err filter shaky path works . > > If without above config and this patch there will be lots of IO > > delay > > in syslog and some paths state change from up to down again and > > again. > > > > Signed-off-by: Chongyun Wu <wu.chongyun@xxxxxxx> > > --- > > multipathd/main.c | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > Hello Chongyun, > > Your patch makes sense to me. Ben has worked much more than myself on > marginal paths recently, so I'd want to see his opinion, too. I've now tested this, and indeed it improves the behavior of the san_path_err algorithm. It's also consistent with how delay_wait_checks used to behave. So: Reviewed-by: Martin Wilck <mwilck@xxxxxxxx> -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
