All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: dm-devel@redhat.com
Subject: Re: Upcall prioritizer for multipath
Date: Mon, 25 Apr 2016 09:49:50 +0200	[thread overview]
Message-ID: <571DCC1E.5000908@suse.de> (raw)
In-Reply-To: <571A1D9E.1000805@emea.nec.com>

On 04/22/2016 02:48 PM, Oliver Mangold wrote:
> I'm working with JBODs and would like to access the disks inside through 
> dm-multipath. For performance reasons I would like to use to prioritizer 
> to pin individual disks to different paths. For testing purposes this 
> can be done with the weighted_path prioritizer, but for production use 
> this is unsatisfactory, as neither the device name nor the SCSI address 
> are persistent over reboots. Thus I wrote a new, simple prioritizer to 
> call an external program to determine what the prio should be. I would 
> like to ask if there is interest to include this (or something similar) 
> upstream (see attached patch).
> 
> Remark: After I did this, I've seen the wwn regex mode in the upcoming 
> 0.6 version, which would also provide a solution to the problem I 
> started out with. But using this would still means one had to recreate 
> multipath.conf each time one replaces a failed disk, so I still believe 
> having an external upcall makes sense in some situations.
> 
> Any thoughts?
> 
Ah, the good old days.
You do remember (of course, as you as a diligent developer would
have had a look through the archives, right?) that we original did
precisely that, namely using 'prio' as an external callout.

The reason why we moved away from this is a deadlock:
When all paths are down (ie the _one_ situation where you absolutely
_need_ multipath to work) you cannot reinstate any paths, as for
reinstating you would need to call the prio program.
Which happens to be an external program, which would need to be
loaded from disk.
Which is not available.
Say goodbye to your machine :-(

So we've moved to using a shared library mechanism, which can be
mlock()ed at boot to avoid these situations.

Hence I would really _not_ use this approach.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

  reply	other threads:[~2016-04-25  7:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-22 12:48 Upcall prioritizer for multipath Oliver Mangold
2016-04-25  7:49 ` Hannes Reinecke [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-04-22 12:52 Oliver Mangold

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=571DCC1E.5000908@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.