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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56AC7535.2090401@suse.de>
Date:	Sat, 30 Jan 2016 09:32:53 +0100
From:	Hannes Reinecke <hare@...e.de>
To:	Benjamin Marzinski <bmarzins@...hat.com>,
	"Nalla, Ravikanth" <ravikanth.nalla@....com>
Cc:	Mike Snitzer <snitzer@...hat.com>,
	"dm-devel@...hat.com" <dm-devel@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"corbet@....net" <corbet@....net>
Subject: Re: [PATCH v2] dm pref-path: provides preferred path load balance
 policy

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@...e.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)