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
next prev parent 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.