 | Viktor Larionov IT osakonna juhataja IT-osakond Salva Kindlustuse AS Tel: (+372) 683 0630 | GSM: (+372) 566 86811 | Viktor.Larionov@xxxxxxxx | www.salva.ee |
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
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
