Linux Device Mapper development
 help / color / mirror / Atom feed
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)

  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