Re: [PATCH v2] dm pref-path: provides preferred path load balance policy

[Hannes Reinecke]

On 01/29/2016 06:50 PM, Benjamin Marzinski wrote:
> On Fri, Jan 29, 2016 at 02:10:52PM +0000, Nalla, Ravikanth wrote:
> > Hi Mike, Hannes, Ben
> > > This seems like a problem that has already been solved with path groups.
> > > If the path(s) in your preferred path group are there, multipath will
>>> use them.  If not, then it will use your less preferred path(s), and
>>> load balance across them > how ever you choose with the path_selectors.
> > > I admit that we don't have a path prioritizer that does a good job of
>>> allowing users to manually pick a specific path to prefer.  But it 
seems
>>> to me that there is > >where we should be solving the issue.
> > >
> > Yes as  mentioned , it appears that we will be able to achieve the same
>> result using the above multipath{...} configuration. However as you
>> mentioned I felt that it is not that user friendly in specify the path
>> to prefer. So when you mentioned about solving the problem there, could
>> you please clarify on what you had in mind and is there anything 
specific
>> from our implementation that can be used there ?
> >
>
> There are two changes that I'm working on.
>
> 1. I'm adding an option for the alua prioritizer so that setting the
> ALUA TPG Preferred Bit will cause the alau prioritizer to put that path
> in a group by itself (with the highest priority). Currently if the
> preferred bit is set for an active/optimized path, and there are other
> active/optimized paths, they are all grouped together, and there is no
> way to change that. So, for people with ALUA enabled hardware, they can
> just enable the option, and set the Preferred Bit.
Hmm? I was under the distinct impression that it's exactly the other way 
round; at least in my code I have this:

                switch(aas) {
                        case AAS_OPTIMIZED:
                                rc = 50;
                                break;
                        case AAS_NON_OPTIMIZED:
                                rc = 10;
                                break;
                        case AAS_LBA_DEPENDENT:
                                rc = 5;
                                break;
                        case AAS_STANDBY:
                                rc = 1;
                                break;
                        default:
                                rc = 0;
                }
                if (priopath && aas != AAS_OPTIMIZED)
                        rc += 80;

ie any path with the 'prio' bit set will be getting a differen priority 
than those without. Consequently they'll be grouped into different 
priority groups.
I'd be surprised if your code is different, but what do I know ...

> 2. For people that need to be able to control the exact priority, I'm
> redoing the weighted handler to allow better ways to specify the paths
> in a presistent manner.  It won't be as simple as the alua method, but
> it will be actually usable, unlike it's current state.
That, however, is greatly appreciated :-)

Cheers,

Hannes
--
Dr. Hannes Reinecke		      zSeries & Storage
hare@xxxxxxx			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)