All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Benjamin Marzinski <bmarzins@redhat.com>,
	device-mapper development <dm-devel@redhat.com>
Cc: Christophe Varoqui <christophe.varoqui@gmail.com>
Subject: Re: [PATCH 1/3] libmultipath: replace PATH_TIMEOUT with PATH_DOWN
Date: Mon, 06 Oct 2014 16:35:02 +0200	[thread overview]
Message-ID: <5432A896.5040205@suse.de> (raw)
In-Reply-To: <1412381483-15757-2-git-send-email-bmarzins@redhat.com>

On 10/04/2014 02:11 AM, Benjamin Marzinski wrote:
> The way the code works, PATH_TIMEOUT is treated mostly like PATH_UP or
> PATH_GHOST by check_path.  If the the path was previously failed,  it will
> even reinstate the path. It will also trigger prio refreshing. It seems
> that PATH_TIMEOUT should be at least as serious as PATH_PENDING, but the
> way the code works, it's not.  In pathinfo, PATH_TIMEOUT gets changed
> directly to PATH_DOWN, which makes sense.  But assuming that's the correct
> thing to do, why have PATH_TIMEOUT at all?
> 
Because a timeout is different from a normal path down.
Timeout means the tur checker is stuck somehow.
And we currently have no real means of resetting it (aio_cancel
doesn't really abort the I/O, is just short-circuit the callback).

So the intention of this patch was that we want to get notified if
a TUR timeout occurs, as this might lead to other subsequent errors.

> The only thing that it does that seems helpful is that when you print out
> the path, instead of it saying that the path is down, it says that the
> path has timed out.  But if we are going to treat is like the path is
> down, then I don't see this being too helpful.  And the way we are treating
> PATH_TIMEOUT right now is definitely not right.
> 
See above. I really would like to be notified for PATH_TIMEOUT
scenarios ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

  reply	other threads:[~2014-10-06 14:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-04  0:11 [PATCH 0/3] miscellaneous multipath patches Benjamin Marzinski
2014-10-04  0:11 ` [PATCH 1/3] libmultipath: replace PATH_TIMEOUT with PATH_DOWN Benjamin Marzinski
2014-10-06 14:35   ` Hannes Reinecke [this message]
2014-10-04  0:11 ` [PATCH 2/3] libmultipath: fix sysfs_get_size bug Benjamin Marzinski
2014-10-04  0:11 ` [PATCH 3/3] Revert "libmultipath: fixup strlcpy" Benjamin Marzinski

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=5432A896.5040205@suse.de \
    --to=hare@suse.de \
    --cc=bmarzins@redhat.com \
    --cc=christophe.varoqui@gmail.com \
    --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.