All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: device-mapper development <dm-devel@redhat.com>
Cc: daniel.milani@connexim.ca
Subject: Re: multipath-tools with STK FLEXLINE 380
Date: Mon, 20 Nov 2006 09:07:00 +0100	[thread overview]
Message-ID: <45616224.4040401@suse.de> (raw)
In-Reply-To: <1163700218.11483.24.camel@localhost.localdomain>

Tony Lapointe wrote:
> Hi list,
> 
> we're trying to get multipath working on a server (which run SLES 10)
> connected to a STK FLEXLINE 380 SAN. This SAN has AVT (Auto Volume
> Transfer) activated and we have two LUNs exported to the server, which
> one on a different preferred path (one on controller A and the other on
> controller B).
> 
> Since the SAN has AVT activated and that we are using preferred path,
> i'm guessing that we have to use group_by_prio policy with the
> mpath_prio_tpc callout program.
> 
> I can see that mpath_prio_tpc get the right priority :
> 
> # mpath_prio_tpc /dev/sda
> 3
> # mpath_prio_tpc /dev/sdb
> 0
> # mpath_prio_tpc /dev/sdd
> 0
> # mpath_prio_tpc /dev/sde
> 3
> 
> and then if i issue "fdisk -l" on /dev/sda and /dev/sde, each LUN stay
> on his preferred controller on the SAN.
> 
> The problem is when i start multipath, it will not coalesces the paths
> together.
> 
> Here's my multipath.conf :
> 
> defaults {
>         udev_dir        /dev
>         polling_interval 10
> 
> 
>         path_grouping_policy    group_by_prio
>         getuid_callout  "/sbin/scsi_id -g -u -s /block/%n"
> 
> 
>         prio_callout    "/sbin/mpath_prio_tpc /dev/%n"
>         path_checker    tur
> 
>         rr_weight       priorities
> 
>         failback        immediate
> 
> #       user_friendly_names yes
> 
> }
Do not use 'rr_weight=priorities'. The priorities handling is currently 
buggered; or, put it the other way round, you will need at least my 
latest fix to get it working. Just remove that line and stay with the 
defaults. That should work.

And as a sidenote: Using 'group_by_prio' and 'rr_weight=priorities' is 
completely pointless, even if 'rr_weight=priorities' should be working.
'group_by_prio' will lump all devices with the same priority into one 
group. And 'rr_weight=priorities' will then modify the 'minio' based on 
the priority. So you can as well directly modify the 'minio' parameter.
'rr_weight=priorities' only makes sense if you have path with different 
priorities in one group, ie when using 'multibus' or 'group_by_serial'.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux Products GmbH		S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de

  reply	other threads:[~2006-11-20  8:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-16 18:03 multipath-tools with STK FLEXLINE 380 Tony Lapointe
2006-11-20  8:07 ` Hannes Reinecke [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-11-21 18:02 Tony Lapointe
2006-11-22 15:29 ` 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=45616224.4040401@suse.de \
    --to=hare@suse.de \
    --cc=daniel.milani@connexim.ca \
    --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.