Linux Device Mapper development
 help / color / mirror / Atom feed
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)

  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