All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "bmarzins@redhat.com" <bmarzins@redhat.com>,
	"wu.chongyun@h3c.com" <wu.chongyun@h3c.com>,
	"mwilck@suse.com" <mwilck@suse.com>
Cc: "guozhonghua@h3c.com" <guozhonghua@h3c.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	"changlimin@h3c.com" <changlimin@h3c.com>,
	"xose.vazquez@gmail.com" <xose.vazquez@gmail.com>,
	"ge.changwei@h3c.com" <ge.changwei@h3c.com>
Subject: Re: [PATCH] multipathd: check and cleanup zombie paths
Date: Tue, 20 Mar 2018 14:58:08 +0000	[thread overview]
Message-ID: <1521557887.3156.5.camel@wdc.com> (raw)
In-Reply-To: <CEB9978CF3252343BE3C67AC9F0086A34295DF37@H3CMLB14-EX.srv.huawei-3com.com>

On Tue, 2018-03-20 at 03:19 +0000, Chongyun Wu wrote:
> Actually there are two scenario:
> (1)Export the LUN to a server at the same time using different LUN nubmer.
> As you mentioned this scenario can be considered a misconfiguration 
> which we might not care about it.
> (2)Export the LUN to a server not at the same time using different LUN 
> number.
> This scenario's operation may be right, the customer just want to 
> reassignment the export relations in the storage.
> But the former export operation leave a residual device in the system 
> which will been adopted by the latter exported device's multipath. Also 
> there are lots of syslog for the former device which actually not 
> exist(at lest customer don't think it exists, the customer want only the 
> new exported device exist)

Hello Chongyun,

It is on purpose that the SCSI core does not remove stale SCSI device nodes.
If you want that these stale SCSI device nodes get removed automatically,
two possible approaches are (there might be other approaches):
* Write a new user space daemon that periodically checks for stale devices
  (e.g. by running grep -aH . /sys/class/scsi_device/*/*/state |
   grep -v running) and that triggers a SCSI rescan if any stale devices are
  found.
* Write a udev rule that listens for SDEV_UA=REPORTED_LUNS_DATA_HAS_CHANGED
  and that triggers a SCSI rescan if this event is triggered by the kernel.

Bart.

  parent reply	other threads:[~2018-03-20 14:58 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
2018-03-20  3:19                     ` Chongyun Wu
2018-03-20  7:36                       ` Martin Wilck
2018-03-20 14:58                       ` Bart Van Assche [this message]
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=1521557887.3156.5.camel@wdc.com \
    --to=bart.vanassche@wdc.com \
    --cc=bmarzins@redhat.com \
    --cc=changlimin@h3c.com \
    --cc=dm-devel@redhat.com \
    --cc=ge.changwei@h3c.com \
    --cc=guozhonghua@h3c.com \
    --cc=mwilck@suse.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 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.