From: Hannes Reinecke <hare@suse.de>
To: Benjamin Marzinski <bmarzins@redhat.com>,
"Nalla, Ravikanth" <ravikanth.nalla@hpe.com>
Cc: Mike Snitzer <snitzer@redhat.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"corbet@lwn.net" <corbet@lwn.net>
Subject: Re: [PATCH v2] dm pref-path: provides preferred path load balance policy
Date: Sat, 30 Jan 2016 09:32:53 +0100 [thread overview]
Message-ID: <56AC7535.2090401@suse.de> (raw)
In-Reply-To: <20160129175059.GB24960@octiron.msp.redhat.com>
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@suse.de +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)
next prev parent reply other threads:[~2016-01-30 8:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 13:31 [PATCH v2] dm pref-path: provides preferred path load balance policy Ravikanth Nalla
[not found] ` <56A231C8.90602@suse.de>
2016-01-22 16:59 ` Mike Snitzer
2016-01-29 14:10 ` Nalla, Ravikanth
2016-01-29 17:50 ` Benjamin Marzinski
2016-01-30 8:32 ` Hannes Reinecke [this message]
2016-01-30 20:25 ` Benjamin Marzinski
2016-01-30 23:32 ` [dm-devel] " Benjamin Marzinski
2016-01-22 17:06 ` Benjamin Marzinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56AC7535.2090401@suse.de \
--to=hare@suse.de \
--cc=bmarzins@redhat.com \
--cc=corbet@lwn.net \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ravikanth.nalla@hpe.com \
--cc=snitzer@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).