<div dir="ltr">Or we could honor arythmetic expressions like "5*alua+weightedpath", giving users more control about preferences (and more opportunities to step on their toes, sure).<div><br></div><div>Another idea, less invasive if possible, but less versatile :</div><div><br></div><div>- Merge the alua prioritizer into the weightedpath prioritizer, given the optimized/non-optimized and other ALUA states are available in the path struct and have their snprint_path_* function and %wildcard.</div><div><br></div><div>- Then weightedpath prio_args can be extended to support additive priorities, like "alua <optimized state>:<... state> 10 serial foo 20"</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 1:40 PM, 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 class="">On 08/01/2016 10:42 AM, Christophe Varoqui wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Mon, Aug 1, 2016 at 9:49 AM, Hannes Reinecke <<a href="mailto:hare@suse.de" target="_blank">hare@suse.de</a><br></span><div><div class="h5">
<mailto:<a href="mailto:hare@suse.de" target="_blank">hare@suse.de</a>>> wrote:<br>
<br>
    On 07/31/2016 09:26 PM, Christophe Varoqui wrote:<br>
<br>
        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<br>
        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>
    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<br>
    priority setup (path groups with distinct priorities and paths<br>
    within them) might not be leading to issues with larger and more<br>
    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<br>
    accessible, or if someone would be using different transports.<br>
<br>
Would something like "prio alua+weightedpath" produce correct priorities<br>
for the path grouping ? where priorities reported by alua would be added<br>
to those reported by weighted path. That syntax extension would reduce<br>
the need to develop more complex prioritizers.<br>
<br>
</div></div></blockquote>
Hmm.<br>
Allowing stacked prioritizers is a nice idea.<br>
But then we need to impose some preference here; if we do not set any restrictions on the value of the prioritizers we end up with a jumble of (essentially unreadable) priorities.<br>
EG if your weightedpath returns values of '5' or '0' they'll be readily obscured by alua information, which uses '5' for the non-optimized path.<br>
<br>
So if we were to got that route we need to restrict the values of the prioritizers to eg 256, and shift the stacked prioritizer values ontop of each other.<br>
EG with a stacked 'prio_alua+weightedpath' we should end up with a priority of 0xAAWW.<br>
With that we can allow up to 4 levels of stacking (or 8 if we extend that to 64 bits), and still keep source-level compability with the original code.<br>
We could even reduce the permissive values for the prioritzers even more; 16 is enough even for ALUA, and that would leave us with enough room of 1024 possible stacking levels :-)<br>
<br>
But in general I like the idea.<div class="HOEnZb"><div class="h5"><br>
<br>
Cheers,<br>
<br>
Hannes<br>
-- <br>
Dr. Hannes Reinecke                Teamlead Storage & Networking<br>
<a href="mailto:hare@suse.de" target="_blank">hare@suse.de</a>                                   <a href="tel:%2B49%20911%2074053%20688" value="+4991174053688" target="_blank">+49 911 74053 688</a><br>
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg<br>
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton<br>
HRB 21284 (AG Nürnberg)<br>
</div></div></blockquote></div><br></div>