[dm-devel] [PATCH 1/4] libmultipath: path latency: fix default base num

2017-11-17 Thread Martin Wilck
I don't think anyone can measure latency to 1% accuracy. It's better to not even pretend to be able to. 10% should be fine even for the most latency-critical environments. Signed-off-by: Martin Wilck --- libmultipath/prioritizers/path_latency.c | 5 +++-- 1 file changed, 3 insertions(+), 2 delet

[dm-devel] [PATCH 4/4] libmultipath: path latency: remove warnings

2017-11-17 Thread Martin Wilck
The warnings at here are pointless. We are looking at a single path only. Firstly, the standdard deviation for this measurement can't be "too low" - the lower, the more precise the measurement, the better. Secondly, a high standard deviation indicates an unstable path with highly variable latency.

[dm-devel] [PATCH 3/4] libmultipath: path latency: simplify getprio()

2017-11-17 Thread Martin Wilck
The log standard deviation can be calculated much more simply by realizing sum_n (x_i - avg(x))^2 == sum_n x_i^2 - n * avg(x)^2 Also, use timespecsub rather than the custom timeval_to_usec, and avoid taking log(0). Signed-off-by: Martin Wilck --- libmultipath/prioritizers/path_latency.c | 7

[dm-devel] [PATCH 0/4] path latency prio fixes

2017-11-17 Thread Martin Wilck
Hi Christophe and Guan, I was hoping to get down to the review before Christophe committed your your patch "calculate standard deviation on a logarithmic scale for prioritizer path_latency". I failed to do this in timely manner, sorry. But I still have some issues with the patch. Please check the

[dm-devel] [PATCH 2/4] libmultipath: path latency: log threshold with p2

2017-11-17 Thread Martin Wilck
This is not a critical error. It just means that the path in question will have low priority (rightly so, if it has >100s latency). Signed-off-by: Martin Wilck --- libmultipath/prioritizers/path_latency.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libmultipath/prioritize

[dm-devel] [PATCH] scsi_dh: add new rdac devices

2017-11-17 Thread Xose Vazquez Perez
Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500. Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220, D240 and D280. Add STK BladeCtlr family, arrays: B210, B220, B240 and B280. These changes were done in multipath-tools time ago. Cc: NetApp RDAC team Cc: Hannes Reinecke

Re: [dm-devel] Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

2017-11-17 Thread Andreas Dilger
On Nov 15, 2017, at 7:18 PM, Qu Wenruo wrote: > > [Background] > Recently I'm considering the possibility to use checksum from filesystem > to enhance device-mapper raid. > > The idea behind it is quite simple, since most modern filesystems have > checksum for their metadata, and even some (btrf

[dm-devel] [PATCH] multipath-tools: refresh kernel-doc from kernel sources

2017-11-17 Thread Xose Vazquez Perez
Cc: Gris Ge Cc: Christophe Varoqui Cc: device-mapper development Signed-off-by: Xose Vazquez Perez --- libdmmp/docs/kernel-doc | 164 ++-- 1 file changed, 118 insertions(+), 46 deletions(-) diff --git a/libdmmp/docs/kernel-doc b/libdmmp/docs/kernel-