Linux Device Mapper development
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: Benjamin Marzinski <bmarzins@redhat.com>, mwilck+gmail@suse.de
Cc: dm-devel@redhat.com
Subject: Re: [PATCH 17/21] libmultipath: pathinfo: don't blank wwid if checker fails
Date: Fri, 26 Oct 2018 11:16:23 +0200	[thread overview]
Message-ID: <080fe2b6dde1b947b9d249276ce1e12b756018c3.camel@suse.com> (raw)
In-Reply-To: <20181025215012.GZ7100@octiron.msp.redhat.com>

On Thu, 2018-10-25 at 16:50 -0500,  Benjamin Marzinski  wrote:
> On Fri, Oct 12, 2018 at 12:27:03AM +0200, Martin Wilck wrote:
> > Blanking a WWID is a dangerous operation. E.g. configure() would
> > consider the path in question as invalid and orphan it if the
> > WWID is blank. Don't do this for possibly transient checker
> > failures.
> > Moreover, we try to determine WWID even if path_offline returns
> > PATH_DOWN in the first place, so why should we not if the checker
> > has a problem?
> > 
> 
> Is PATH_WILD a transient error?  Clearly we have cases where
> PATH_UNCHECKED happens because of a transient error. What's the case
> that you are worried about where we temporarily get a PATH_WILD, but
> we
> think we should continue will setting up the path?

My mentioning of a "transient" error condition is misleading. 

But do I think that the patch is correct. In particular with the
previous changes in the series, PATH_WILD would mean that the checker
couldn't do it's job and simply has no information whether or not the
path is good. IMO it is wrong not to try to obtain a WWID, or even
blank an already retrieved WWID, in this case.

Do you disagree?

Regards,
Martin

-- 
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

  reply	other threads:[~2018-10-26  9:16 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11 22:26 [PATCH 00/21] libmultipath: checkers overhaul Martin Wilck
2018-10-11 22:26 ` [PATCH 01/21] libmultipath: fix use of uninitialized memory in write() Martin Wilck
2018-10-25 20:31   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 02/21] libmultipath: fix memory leaks from scandir() use Martin Wilck
2018-10-25 20:31   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 03/21] libmultipath/checkers: replace message by msgid Martin Wilck
2018-10-25 20:57   ` Benjamin Marzinski
2018-10-25 21:36     ` Martin Wilck
2018-10-11 22:26 ` [PATCH 04/21] libmultipath/checkers: cciss_tur: use message id Martin Wilck
2018-10-25 20:57   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 05/21] libmultipath/checkers: directio: " Martin Wilck
2018-10-25 20:58   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 06/21] libmultipath/checkers: emc_clariion: " Martin Wilck
2018-10-25 20:58   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 07/21] libmultipath/checkers: hp_sw: " Martin Wilck
2018-10-25 20:58   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 08/21] libmultipath/checkers: rdac: " Martin Wilck
2018-10-25 20:59   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 09/21] libmultipath/checkers: readsector0: " Martin Wilck
2018-10-25 21:02   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 10/21] libmultipath/checkers: tur: " Martin Wilck
2018-10-25 21:32   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 11/21] multipathd: improve checker message logging Martin Wilck
2018-10-25 21:32   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 12/21] libmultipath/checkers: support unsupported paths Martin Wilck
2018-10-25 21:33   ` Benjamin Marzinski
2018-10-11 22:26 ` [PATCH 13/21] libmultipath: clariion checker: leave unsupported paths alone Martin Wilck
2018-10-25 21:41   ` Benjamin Marzinski
2018-10-26  9:01     ` Martin Wilck
2018-10-11 22:27 ` [PATCH 14/21] libmultipath: hp_sw " Martin Wilck
2018-10-25 21:42   ` Benjamin Marzinski
2018-10-11 22:27 ` [PATCH 15/21] libmultipath: rdac " Martin Wilck
2018-10-25 21:42   ` Benjamin Marzinski
2018-10-11 22:27 ` [PATCH 16/21] libmultipath: tur " Martin Wilck
2018-10-25 21:42   ` Benjamin Marzinski
2018-10-11 22:27 ` [PATCH 17/21] libmultipath: pathinfo: don't blank wwid if checker fails Martin Wilck
2018-10-25 21:50   ` Benjamin Marzinski
2018-10-26  9:16     ` Martin Wilck [this message]
2018-10-26 15:11       ` Benjamin Marzinski
2018-10-11 22:27 ` [PATCH 18/21] multipathd: check_path: improve logging for "unusable path" case Martin Wilck
2018-10-25 21:50   ` Benjamin Marzinski
2018-10-11 22:27 ` [PATCH 19/21] libmultipath: coalesce_paths: improve logging of orphaned paths Martin Wilck
2018-10-25 21:50   ` Benjamin Marzinski
2018-10-11 22:27 ` [PATCH 20/21] libmultipath: sync_map_state: log failing paths Martin Wilck
2018-10-25 21:52   ` Benjamin Marzinski
2018-10-11 22:27 ` [PATCH 21/21] libmultipath/checkers: cleanup class/instance model Martin Wilck
2018-10-25 21:52   ` 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=080fe2b6dde1b947b9d249276ce1e12b756018c3.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=mwilck+gmail@suse.de \
    /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