<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 29 Aug 2017, at 2:02, Xose Vazquez Perez <<a href="mailto:xose.vazquez@gmail.com" class="">xose.vazquez@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 08/28/2017 03:59 PM, Arnon Yaari wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On 25 Aug 2017, at 3:26, Xose Vazquez Perez <<a href="mailto:xose.vazquez@gmail.com" class="">xose.vazquez@gmail.com</a>> wrote:<br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On 08/22/2017 03:37 PM, Arnon Yaari wrote:<br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">-<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>.pgfailback = -FAILBACK_IMMEDIATE,<br class="">+<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>.pgfailback = 30,<br class=""></blockquote></blockquote></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Why is it needed?<br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class="">All the values suggested here are the values that the company’s interoperability<br class="">team found work best for the product on Linux. The timeout values are there<br class="">because in some upgrade scenarios we don’t want to fail devices until the<br class="">upgrade finishes.<br class=""></blockquote><br class="">Were they tested with a *current* kernel and multipath-tools?<br class=""></div></div></blockquote><div><br class=""></div><div>Of course. We do extensive interoperability testing on RHEL, CentOS, Ubuntu, SLES, on old and all new versions.</div><div>The way our "hot upgrade" process works can cause device loss if these values are not in place.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">I don’t think there is a reason to add in-line comments in the code to<br class="">explain the values (none of the other vendors are doing that).<br class=""></blockquote><br class="">It should be documented in the body of the git patch(changelog).<br class=""><br class="">Anything other than default values must be documented.<br class="">This is a standard request: <a href="https://marc.info/?t=149850399700003" class="">https://marc.info/?t=149850399700003</a><br class=""></div></div></blockquote><div><br class=""></div><div>All vendor config commits I see just link to the vendor support docs, which makes sense because the vendor config is the authority on what needs to be set, and the docs themselves are the explanation (perhaps we need to add the reasons to the docs...).</div><div>I will change the patch message anyway.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">+<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>.selector = "round-robin 0",<br class=""></blockquote><br class="">round-robin is the dumbest, queue-length is smarter and<br class="">service-time is the smartest and default selector.<br class=""></blockquote><br class="">Regardless of which algorithm is “dumbest” or “smartest”, round-robin<br class="">is a legitimate path selection algorithm that the vendor decided works<br class="">best with its product. The vendor knows its product best :)<br class="">The product’s customers set the values suggested here (manually or<br class="">using tools provided by the vendor), whether they are upstream or not.<br class=""></blockquote><br class="">In an *ideal environment* , "round-robin" "queue-length" and "service-time"<br class="">work the same way, doing a round robin distribution.<br class=""><br class="">But when things get ugly, "round-robin" could lost data.<br class=""><br class="">"service-time" works much better in any environment, even asymmetrical.<br class="">In highly congested links, with different link speeds, faulty paths, ...<br class=""><br class="">path_selector is like TCP congestion control algorithm.<br class=""></div></div></blockquote><div><br class=""></div><div>We may decide to change this behavior in the future. I will pass your input to our product team. I don’t expect it’s something we’ll change in a short time frame without more discussion and testing.</div><div>We don’t see how round-robin can lose data. Can you please elaborate?</div><div>In any case, this is our current configuration that is set in customer environments. For better or worse, not accepting this doesn’t change anything other than inconveniencing users.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">+<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>.no_path_retry = NO_PATH_RETRY_FAIL,<br class=""></blockquote><br class="">Default value.<br class=""></blockquote><br class="">Isn’t the default NO_PATH_RETRY_UNDEF?<br class=""></blockquote><br class=""><br class="">Practically it's the same: <a href="https://marc.info/?l=dm-devel&m=147854542623733" class="">https://marc.info/?l=dm-devel&m=147854542623733</a><br class=""></div></div></blockquote><div><br class=""></div><div>I’m not convinced it’s the same. The message you linked says it takes what is in the “features” line, which can be changed.</div><div>Even if it’s implicitly the same, it’s not really the default. We prefer to specify this explicitly.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class="">Thank you.<br class=""></div></div></blockquote></div><br class=""></body></html>