All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Marzinski <bmarzins@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: multipath prio_callout broke from 5.2 to 5.3
Date: Fri, 24 Apr 2009 01:27:59 -0500	[thread overview]
Message-ID: <20090424062759.GZ15911@ether.msp.redhat.com> (raw)
In-Reply-To: <49F0AEA0.9050803@nrel.colostate.edu>

On Thu, Apr 23, 2009 at 12:08:32PM -0600, Ty! Boyack wrote:
> This thread has been great information since I'm looking at the same type 
> of thing.  However it raises a couple of (slightly off-topic) questions for 
> me. 
> My recent upgrade to fedora 10 broke my prio_callout bash script just like 
> you described, but my getuid_callout (a bash script that calls udevadm, 
> grep, sed, and iscsi_id) runs just fine.  Are the two callouts handled 
> differently?

Fedora 10 uses the same method as upstream, priority callouts have been
replaced by priority modules. These are dynamic shared objects that get
loaded by multipath.  Because of this, multipath doesn't use a private
namespace, so it can use scripts without restrictions for the getuid_callout.

>
> Also, is there an easy way to know what tools are in the private namespace 
> already?  My prio_callout script calls two other binaries: /sbin/udevadm 
> and grep.  If I go to C-code, handling grep's functions myself is no 
> problem, but I'm not confident about re-implementing what udevadm does.  
> Can I assume that since /sbin/udevadm is in /sbin that it will be available 
> to call via exec()?  Or would I be right back where we are with the bash 
> scripting, as in having to include a dummy device as you described?

Sorry, the C code is necessary now.

> Finally, in my case I've got two redundant iscsi networks, one is 1GbE, and 
> the other is 10GbE.  In the past I've always had symetric paths, so I've 
> used round-robin/multibus.  But I want to focus traffic on the 10GbE path, 
> so I was looking at using the prio callout.  Is this even necessary?  Or 
> will round-robin/multibus take full advantage of both paths?  I can see 
> round-robin on that setup resulting in either around 11Gbps or 2 Gbps, 
> depending on whether the slower link becomes a limiting factor.  I'm just 
> wondering if I am making things unnecessarily complex by trying to set 
> priorities.

With round-robin, you will send half your IO to the slow path.  A
priority callout makes sense here.

> Thanks for all the help.
>
> -Ty!
>
> -- 
> -===========================-
>  Ty! Boyack
>  NREL Unix Network Manager
>  ty@nrel.colostate.edu
>  (970) 491-1186
> -===========================-
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

  parent reply	other threads:[~2009-04-24  6:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1181572819.1578541239520146435.JavaMail.root@zimbra16-e3.priv.proxad.net>
2009-04-12  7:13 ` multipath prio_callout broke from 5.2 to 5.3 christophe.varoqui
2009-04-13  9:00   ` John A. Sullivan III
2009-04-13 18:57     ` Benjamin Marzinski
2009-04-13 19:56       ` John A. Sullivan III
2009-04-13 20:37         ` Benjamin Marzinski
2009-04-13 20:55           ` Benjamin Marzinski
2009-04-13 21:49           ` John A. Sullivan III
2009-04-23 18:08             ` Ty! Boyack
2009-04-23 18:22               ` John A. Sullivan III
2009-04-24  3:09                 ` Ty! Boyack
2009-04-24  3:44                   ` John A. Sullivan III
2009-04-24  6:27               ` Benjamin Marzinski [this message]
2009-04-24 15:31                 ` Christopher Chen
2009-04-12  3:54 John A. Sullivan III
2009-04-12  4:07 ` John A. Sullivan III

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=20090424062759.GZ15911@ether.msp.redhat.com \
    --to=bmarzins@redhat.com \
    --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.