From: Martin Wilck <mwilck@suse.com>
To: Benjamin Marzinski <bmarzins@redhat.com>,
Chongyun Wu <wu.chongyun@h3c.com>
Cc: 'Xose Vazquez Perez' <xose.vazquez@gmail.com>,
Guozhonghua <guozhonghua@h3c.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
Changwei Ge <ge.changwei@h3c.com>,
Changlimin <changlimin@h3c.com>
Subject: Re: [PATCH] multipathd: check and cleanup zombie paths
Date: Mon, 19 Mar 2018 22:42:06 +0100 [thread overview]
Message-ID: <1521495726.3798.141.camel@suse.com> (raw)
In-Reply-To: <20180309162243.GE14513@octiron.msp.redhat.com>
On Fri, 2018-03-09 at 10:22 -0600, Benjamin Marzinski wrote:
> On Fri, Mar 09, 2018 at 06:47:30AM +0000, Chongyun Wu wrote:
> > On 2018/3/8 23:45, Benjamin Marzinski wrote:
> > >
> > > If there are multiple routes to the storage, Some of them can be
> > > down,
> > > even if everything is fine on the storage. This will cause some
> > > paths
> > > to be up and some to be down, regardless of the state of the LUN.
> > > In
> > > every other multipath case but this one, there is just one LUN,
> > > and not
> > > all the paths have the same state.
> > >
> > > Ideally, there would be a way to determine if a path is a zombie,
> > > simply
> > > by looking at it alone. The additional sense code "LOGICAL UNIT
> > > NOT
> > > SUPPORTED" that you posted earlier isn't one that I recall seeing
> > > for
> > > failed multipathd paths. I'll check around more, but a quick
> > > look makes
> > > it appear that this code is only used when you are accessing a
> > > LUN that
> > > really isn't there. It's possible that the TUR checker could
> > > return a
> > > special path state for this, that would cause multipathd to
> > > remove the
> > > device. Also, even if that additional sense code is only
> > > supposed to be
> > > used for this condition, we should still removing a device that
> > > returns
> > > it configurable, because I can almost guarantee that there will
> > > be a
> > > scsi device that does follow the standard for this.
> > >
> >
> > Hi Ben,
> > You just mentioned *the TUR checker could return a special path
> > state
> > for this*, what is the special path state? Thanks~
> >
>
> We would have to add a new state, like PATH_NOT_SUPPORTED, that the
> TUR
> checker could return in this case. multipathd could be configured to
> remove the path if it returned this state. If it wasn't configured to
> do
> so, multipathd would just change the state to PATH_DOWN.
Is it really multipathd's job to do remove devices that return "LOGICAL
UNIT NOT SUPPORTED"? To me it sounds like a misconfiguration on the
SCSI/storage level, and I'm unsure if that's a thing multipathd should
mess with.
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
next prev parent reply other threads:[~2018-03-19 21:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CEB9978CF3252343BE3C67AC9F0086A34295C462@H3CMLB14-EX.srv.huawei-3com.com>
[not found] ` <1520325779.4131.4.camel@suse.com>
[not found] ` <CEB9978CF3252343BE3C67AC9F0086A34295C9D0@H3CMLB14-EX.srv.huawei-3com.com>
[not found] ` <1520349519.4131.20.camel@suse.com>
[not found] ` <CEB9978CF3252343BE3C67AC9F0086A34295CA7D@H3CMLB14-EX.srv.huawei-3com.com>
[not found] ` <1520426679.11340.5.camel@suse.com>
[not found] ` <CEB9978CF3252343BE3C67AC9F0086A34295CF62@H3CMLB14-EX.srv.huawei-3com.com>
2018-03-08 15:54 ` [PATCH] multipathd: check and cleanup zombie paths Xose Vazquez Perez
2018-03-09 6:11 ` Chongyun Wu
[not found] ` <20180308154435.GB14513@octiron.msp.redhat.com>
2018-03-09 6:47 ` Chongyun Wu
2018-03-09 10:47 ` Xose Vazquez Perez
2018-03-09 16:22 ` Benjamin Marzinski
2018-03-19 21:42 ` Martin Wilck [this message]
2018-03-20 3:19 ` Chongyun Wu
2018-03-20 7:36 ` Martin Wilck
2018-03-20 14:58 ` Bart Van Assche
2018-03-20 15:12 ` Xose Vazquez Perez
2018-03-20 15:14 ` Bart Van Assche
2018-03-20 15:19 ` Martin Wilck
2018-03-21 1:54 ` Chongyun Wu
2018-03-21 19:56 ` Bart Van Assche
2018-03-22 1:58 ` Chongyun Wu
2018-03-22 3:40 ` Chongyun Wu
2018-03-22 15:18 ` Bart Van Assche
2018-03-21 1:17 ` Chongyun Wu
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=1521495726.3798.141.camel@suse.com \
--to=mwilck@suse.com \
--cc=bmarzins@redhat.com \
--cc=changlimin@h3c.com \
--cc=dm-devel@redhat.com \
--cc=ge.changwei@h3c.com \
--cc=guozhonghua@h3c.com \
--cc=wu.chongyun@h3c.com \
--cc=xose.vazquez@gmail.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