<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 9:49 AM, Hannes Reinecke <span dir="ltr"><<a href="mailto:hare@suse.de" target="_blank">hare@suse.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 07/31/2016 09:26 PM, Christophe Varoqui wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ben, Hannes,<br>
<br>
Can you review this patch, adding a new 'serial' keyword to the<br>
weightedpath prioritizer.<br>
<br>
I compile-tested it only, as I have no testing environment at hand at<br>
the moment.<br>
<br>
I commited it in a separate 'weightedpath-serial' branch for now.<br>
<br>
<a href="http://git.opensvc.com/?p=multipath-tools/.git;a=commitdiff;h=4dd16d99281104fc3504ad73626894a5c3702fb3" rel="noreferrer" target="_blank">http://git.opensvc.com/?p=multipath-tools/.git;a=commitdiff;h=4dd16d99281104fc3504ad73626894a5c3702fb3</a><br>
<br>
Thanks,<br>
Christophe Varoqui<br>
OpenSVC<br>
<br>
</blockquote></span>
Well.<br>
In general, sure, fine, I don't have any issues with that.<br>
If the customer wants to diddle with his array that way...<br>
<br>
The more general problem I'm seeing is that our current two-layered priority setup (path groups with distinct priorities and paths within them) might not be leading to issues with larger and more complex scenarios.<br>
<br>
ATM we already have the problem that clustered scenarios like this:<br>
<br>
Storage node 1(active):<br>
  Path 1 (optimal):<br>
    LUN 1, LUN2<br>
  Path 2 (non-optimal):<br>
    LUN 1, LUN2<br>
<br>
Storage node 2(passive):<br>
  Path 1(optimal):<br>
     LUN 1, LUN2<br>
  Path 2(non-optimal):<br>
     LUN 1, LUN2<br>
<br>
can not be represented properly with multipath tools.<br>
We are forced to either<br>
a) set 'storage node 2' to 'failed', which would kill<br>
   any cluster instance accessing only 'storage node 2'<br>
or<br>
b) map all priorities from 'storage node 2' to '0',<br>
   thereby losing all priority information<br>
<br>
Things become even more convoluted if both storage nodes are in fact accessible, or if someone would be using different transports.<br>
<br></blockquote><div>Would something like "prio alua+weightedpath" produce correct priorities for the path grouping ? where priorities reported by alua would be added to those reported by weighted path. That syntax extension would reduce the need to develop more complex prioritizers.</div><div><br></div><div>The prio_args to prio mapping, wouldn't be nice though.</div><div><br></div><div>Concerning transports, we can also extend the weightedpath prioritizer, and if the multi-prioritizer setup is implemented we could even weight on serial+transport with a "prio weighedpath+weightedpath" setup.</div><div><br></div></div></div></div>