On Sat, Jan 30, 2016 at 09:32:53AM +0100, Hannes Reinecke wrote:
> 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 ...
No. That's only true if the path doesn't have AAS_OPTIMIZED set. So if
you have a non-optimized path with the pref bit set, it will be in a
group by itself. If the path is AAS_OPTIMIZED, the pref bit is ignored.
Like I mentioned before, you are the one who changed this
commit b330bf8a5e6a29b51af0d8b4088e0d8554e5cfb4
Author: Hannes Reinecke <hare@xxxxxxx>
Date: Tue Jul 16 09:12:54 2013 +0200
alua: Do not add preferred path priority for active/optimized
When a path is in active/optimized we should disregard the
'preferred path' bit when calculating the priority.
Otherwise we'll end up with having two different priorities
(one for 'active/optimized (preferred)' and one for
'active/optimized (non-preferred)').
Which will result in two different path groups and a
sub-optimal path usage.
Signed-off-by: Hannes Reinecke <hare@xxxxxxx>
Before this commit, it always used the pref bit. Again, like I said
before, I'm saying that this was the wrong thing to do. The Spec is
pretty vague on what you should expect to happen when you set to pref
bit. When the path was in a group by itself, I got complaints. Now that
the path is is a group with other active/optimized paths, I get
complaints. The only answer is to allow the user to say what they want
the pref bit to mean.
-Ben
> >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)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
