From: Hannes Reinecke <hare@suse.de>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: Powerpath vs dm-multipath - two points of FUD?
Date: Mon, 15 Sep 2014 08:54:17 +0200 [thread overview]
Message-ID: <54168D19.3010908@suse.de> (raw)
In-Reply-To: <454E18A46D7B064CA63B41E99AD179508A754100@MX103CL02.corp.emc.com>
Hi Jerome,
On 09/14/2014 08:44 PM, Levy, Jerome wrote:
>> Firstly, apologies if this is a common topic and my intentions are not
>> to start a flame war. I've googled extensively but haven't found
>> specific information to address my queries, so I thought I would turn here.
>
> At the risk of getting involved in a religious discussion (disclaimer: I am an EMC employee
> and was an advanced support engineer for both PowerPath and
dm-multipath) I thought I'd pass
> along a few thoughts that might help:
>
> PowerPath costs money. dm-multipath is included with the OS distro.
>
[ .. ]
>
> PowerPath contains proprietary load sensing and balancing algorithms which may help performance
> in a given situation. (It does. I've seen them.) YMMV.
>
Unfortunately I'll have to agree with Jerome here.
If you have in-depth knowledge of the array you can cut some corners
and optimize for certain scenarios.
We haven't, and so we can't.
Neither can we estimate how _likely_ such a scenario is;
We live on the assumption that it's not, and that most customers are
happily living with the standard setups.
Surprisingly enough, most do :-)
> Request size and other switching options can be useful in a number
> of specific situations -- some may call them corner cases, but
streaming
> media, heavy database backups, large dataset transfers, and others
have
> been shown to benefit from alternate PowerPath policies.
>
See above. Of course.
> As Hannes points out, PowerPath is supported by EMC. If things don't work,
> you have someone to call. That can be comforting in the middle of
the night :)
>
But so is device-mapper multipath :-)
Sorry.
> I've seen both PowerPath and native multipath solutions provide a lot of
> value in different ways, and the decision as to which to use is
not always
> clear-cut. Hope this helps!
>
Thanks for that. It surely helps.
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:[~2014-09-15 6:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-14 18:44 Powerpath vs dm-multipath - two points of FUD? Levy, Jerome
2014-09-15 6:54 ` Hannes Reinecke [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-09-09 16:50 Rob
2014-09-10 10:04 ` Bryn M. Reeves
2014-09-14 8:39 ` Hannes Reinecke
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=54168D19.3010908@suse.de \
--to=hare@suse.de \
--cc=dm-devel@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