Re: multipath-tools: scsi_id based path priorities and multiple prioritizers

[Viktor Larionov <Viktor.Larionov@salva.ee>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2690 bytes --]

Hi Christophe!


Viktor Larionov
IT osakonna juhataja
IT-osakond
Salva Kindlustuse AS
Tel: (+372) 683 0630 | GSM: (+372) 566 86811 | Viktor.Larionov@salva.ee | www.salva.ee
(SMX)338844

On 18.05.2013 16:40, Christophe Varoqui wrote:

>> So, we poked up with code a bit, and wrote up a custom prioritizer,
>> called sg_id. (patch for the latest multipath-tools available here:
>> http://viktor.ee/multipath-tools-patches/sg_id_prio.patch [1])
>
> Would the existing weightedpath work for you ?
>

It's a shame I missed weighted path while googling for a solution in 
the
first place, thanks for the hint. I checked into that, and I should say
it's very alike with what we have done in sg_id_prio patch. I've 
briefly
checked into weighted path and I don't quite like the concept of the
design.
Weighted path as suggested wants you to pass the arguments via the same
"prio" conf param which is used to indicate the prioritizer(s) to be
used. I don't see much sense in that, keeping in mind that you have a
"prio_args" param designed initially for that purpose.
That is also the reason why weighted path needs to hack deep into the
libmultipath architecture. (while the modular nature of libmultipath 
sees
that the prioritizer is a separate shared lib and has nothing much to
hack in the main core). From my point that's not quite right.
When it comes to enabling multiple prioritizers in a row (our second
patch) - weighted path approach makes it impossible, as it passes its 
own
arguments on the prio line.

So answering your question - I think that weighted path would not solve
our problem, mainly due to its architectural approach and difficulties
  with multi prioritizer setup when dealing with weighted path.

I also agree with Kiyoshi comment to weighted path back from 2008. The
whole story of assigning a static priority based on hbtl or node name
pattern from my oppinion is useless on it's own. It's a great extra, 
for
use cases as ours, where you just need to tweak a little the priority
given by a more intelligent prioritizer. (that's why multiprio)

On the other hand, weighted path has a couple of neat features like
setting a static priority not only based on hbtl, but also on a device
node name. sg_io_prio supports hbtl only as this is less likely to
change. (though not totally excluded of course). If disregard this 
point,
and the architectural difference both modules are identical.

I personally think that either weighted path should implement a more
intelligent way of operation (utilize prio_args and not mess with the
basic architecture of libmultipath) or our prio_sg_id should support
device node names (which is a half an hour work we can do).

Cheers!
vik

[-- Attachment #1.1.2: Type: text/html, Size: 4600 bytes --]

[-- Attachment #1.2: 5VfDWTiyBUOwvJT.gif --]
[-- Type: image/gif, Size: 6207 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]