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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.