From: Hannes Reinecke <hare@suse.de>
To: sekharan@linux.vnet.ibm.com
Cc: dm-devel <dm-devel@redhat.com>
Subject: Re: rdac priority checker changing priorities
Date: Mon, 04 May 2009 12:43:50 +0200 [thread overview]
Message-ID: <49FEC6E6.6070105@suse.de> (raw)
In-Reply-To: <1241114743.11905.13.camel@chandra-ubuntu>
Hi Chandra,
Chandra Seetharaman wrote:
> Hannes,
>
> I think we need to revisit the priority value we provide for preferred
> path(4) relative to active path (2) and non-preferred(1).
>
> Consider the following scenario:
>
> Access to a lun thru 2 preferred and 2 non-preferred path. Lets call
> path group with preferred paths as pg1 and with non-preferred paths as
> pg2.
>
> Initially pg1 has priority of 8 and pg2 has priority of 2. pg1 is chosen
> and I/O goes thru pg1, all good.
>
> Both the paths in pg1 fails, pg2 has been made the active path group and
> I/O is sent thru that path and since it became "active", its priority
> raises to 6 ( 2 path times (active + non-preferred)).
>
> When one of the paths in pg1 comes back, one would expect the failback
> to happen. It doesn't happen as pg1's priority (4) is smaller than that
> of pg2 (6). Which is not correct.
>
Is this really a valid case?
This means we'll have a setup like this:
rdac
pg1
sda failed
sdb failed
pg2
sdc active
sdd active
Correct?
So, given your assumptions, the proposed scenario would be represented
like this:
rdac
pg1
sda active
sdb failed
pg2
sdc active
sdd active
So it is really a good idea to switch paths in this case? The 'sdb'
path would not be reachable here, so any path switch command wouldn't
have been received, either. I'm not sure _what_ is going to happen
when we switch paths now and sdb comes back later; but most likely
the entire setup will be messed up then:
sda (pref & owned) 6
sdb 0
sdc (sec) 1
sdd (sec & owned) 3
and we'll be getting the path layout thoroughly jumbled then.
So I don't really like this idea. We should only be switching
paths when _all_ paths of a path group become available again.
Providing not all paths have failed in the active group, of course.
Then we should be switching paths regardless.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
next prev parent reply other threads:[~2009-05-04 10:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-29 22:34 rdac priority checker changing priorities Lucas Brasilino
2009-04-30 6:25 ` Hannes Reinecke
2009-04-30 18:05 ` Chandra Seetharaman
2009-05-04 10:43 ` Hannes Reinecke [this message]
2009-05-04 17:30 ` Chandra Seetharaman
2009-06-23 0:47 ` Chandra Seetharaman
2009-06-23 6:20 ` Hannes Reinecke
2009-05-05 17:59 ` Lucas Brasilino
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=49FEC6E6.6070105@suse.de \
--to=hare@suse.de \
--cc=dm-devel@redhat.com \
--cc=sekharan@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox