From: Tore Anderson <tore@linpro.no>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: Round Robin vs Active/Passive
Date: Fri, 23 May 2008 10:00:15 +0200 [thread overview]
Message-ID: <4836798F.4060100@linpro.no> (raw)
In-Reply-To: <20080523071654.GB380@pentland.suse.de>
* Hannes Reinecke
> No. Alua is completely different. You have to use
>
> prio_callout "/sbin/mpath_prio_alua /dev/%n"
>
> for this.
> Although the normal EMC configuration continues to work, too.
> And also note that you have to change the failover mode
> to '4' to enable ALUA on the Clariion.
Hmm, interesting. Apologies if I've been spreading misinformation!
Now you made me curious. How does using an array (in ALUA failover mode
4) with my configuration:
device {
vendor DGC
product *
product_blacklist LUNZ
path_grouping_policy group_by_prio
path_checker tur
no_path_retry queue
prio_callout "/sbin/mpath_prio_emc /dev/%n"
failback immediate
}
differ from using the ALUA specific code in multipath-tools? I believe
it would look something like this?
device {
vendor DGC
product *
product_blacklist LUNZ
path_grouping_policy group_by_prio
path_checker tur
no_path_retry queue
prio_callout "/sbin/mpath_prio_alua /dev/%n"
failback immediate
hardware_handler "1 alua"
}
I assume the ALUA bits are able to explicitly tell the CLARiiON to
transfer volume ownership from one controller to another (something I
don't think is desired in clustered environments anyway - the array
should have a better understanding of the optimal location of the volume
than the hosts, who could be in disagreement and end up moving the
volume back and forth), but what other differences are there?
I'm speaking strictly from a user's point of view here - the differences
"under the hood" isn't that interesting to me as long as it ends up
working the same way and in an equally reliable manner.
Regards,
--
Tore Anderson
next prev parent reply other threads:[~2008-05-23 8:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8a6b34b03e0524aa66c862534fee9b7a@www3.mail.volny.cz>
2008-05-21 11:41 ` INFO: task md2_resync:7950 blocked for more than 120 seconds Neil Brown
2008-05-21 14:48 ` Round Robin vs Active/Passive Craig Simpson
2008-05-21 15:32 ` Craig Simpson
2008-05-21 18:23 ` Tore Anderson
2008-05-21 20:21 ` Craig Simpson
2008-05-21 21:01 ` Tore Anderson
2008-05-21 21:49 ` Craig Simpson
2008-05-21 23:41 ` Craig Simpson
2008-05-22 12:00 ` Tore Anderson
2008-05-22 8:24 ` Domenico Viggiani
2008-05-22 11:57 ` Tore Anderson
2008-05-23 7:16 ` Hannes Reinecke
2008-05-23 8:00 ` Tore Anderson [this message]
2008-05-23 8:55 ` Hannes Reinecke
2008-05-23 9:42 ` Tore Anderson
2008-05-23 10:36 ` Domenico Viggiani
2008-05-23 10:46 ` Tore Anderson
2008-05-23 21:16 ` Sebastian Herbszt
2008-06-05 6:54 ` Tore Anderson
2008-06-05 7:20 ` Hannes Reinecke
2008-06-06 7:19 ` Tore Anderson
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=4836798F.4060100@linpro.no \
--to=tore@linpro.no \
--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.