[dm-devel] [PATCH] multipathd: LUN protection by checking path's wwid change status

[Benjamin Marzinski]

I've actually managed to reproduce this issue with the latest code.  All
it takes is two machines in the same FC zone, with one of them having a
FC driver that supports target mode and LIO.

To do it:
You can grab TGT_WWPN and INIT_WWPN from
/sys/class/fc_host/host<n>/port_name

On the target machine (assuming you're using the ql2xxx module)
load the FC driver in target mode
# modprobe qla2xxx qlini_mode=disabled

start up the LIO target.service
# service target start

configure the setup in targetcli
# targetcli
/> qla2xxx/ create <TGT_WWPN>
/> backstores/fileio create file1 <FILE_1> 100M
/> backstores/fileio create file2 <FILE_2> 100M
/> qla2xxx/<TGT_WWPN>/luns create /backstores/fileio/file1 1
/> qla2xxx/<TGT_WWPN>/luns create /backstores/fileio/file2 2
/> qla2xxx/<TGT_WWPN>/acls create <INIT_WWPN>

On the host machine:
discover the LIO devices on each FC host
# echo 1 > /sys/class/fc_host/host<N>/issue_lip

You should have two multipath devices now

On the target machine:
switch the LUNs
/> qla2xxx/<TGT_WWPN>/acls/<INIT_WWPN> delete 1
/> qla2xxx/<TGT_WWPN>/acls/<INIT_WWPN> delete 2
/> qla2xxx/<TGT_WWPN>/acls/<INIT_WWPN> create 2 /backstores/fileio/file1
/> qla2xxx/<TGT_WWPN>/acls/<INIT_WWPN> create 1 /backstores/fileio/file2

This will often generate a change event, but not on every path,
leaving some paths as part of the wrong multipath device.

I'll post a patchset based on Chongyun's patch shortly to deal with
this.

-Ben

On Fri, Jan 08, 2021 at 11:13:01AM +0800, Chongyun Wu wrote:
> Thanks Martin, I will try to reproduce this issue with the latest version
> when the enviroments ready, if reproduce it again I will let you know,
> thanks again~
> 
> On 2021/1/7 19:27, Martin Wilck wrote:
> >On Thu, 2021-01-07 at 10:23 +0800, Chongyun Wu wrote:
> >>Hello Martin,
> >>Thanks for view this patch.
> >>
> >>On 2021/1/7 5:10, Martin Wilck wrote:
> >>>Hello Chongyun,
> >>>
> >>>On Mon, 2020-12-28 at 11:34 +0800, Chongyun Wu wrote:
> >>>>   From 37c74873acfc1587e79a6504ca3d42b8fa00d49e Mon Sep 17
> >>>>00:00:00
> >>>>2001
> >>>>
> >>>>From: Chongyun Wu <wucy11 at chinatelecom.cn>
> >>>>Date: Mon, 21 Dec 2020 09:51:20 +0800
> >>>>Subject: [PATCH] multipathd: LUN data protection by checking
> >>>>path's
> >>>>wwid
> >>>>    change status
> >>>>
> >>>>Issue description:
> >>>>A) Device sda and sdb correspend to LUN1 and LUN2 in storage
> >>>>backend
> >>>>and
> >>>>the upper layer application uses those two devices.
> >>>>B) Doing illegal operation: unmapping LUN1 and LUN2 in storage
> >>>>backend,
> >>>>and export LUN2 and LUN1 to host with exchanged assignment
> >>>>relation
> >>>>between sda and sdb.
> >>>>C) The upper layer application run for a while and found that the
> >>>>data
> >>>>in both LUN1 and LUN2 has been corrupted.
> >>>
> >>>Can you please be explicit about which multipath-tools version you
> >>>have
> >>>tested? I thought we had the wwid change issues covered. Ben and I
> >>>have
> >>>been putting quite some effort into this recently. Of course we can
> >>>be
> >>>wrong, but I'd like to understand the issue fully.
> >>>
> >>The test version is 0.8.3.
> >
> >A test with 0.8.5 would be in necessary, then. The INIT_REMOVED logic
> >has been added after 0.8.4.
> >>>
> >>>Please confirm that you've been using the latest version from
> >>>Christophe's repo (or better even, from my upstream-queue), and
> >>>provide
> >>>-v3 logs showing what goes wrong.
> >>Sorry Martin, I haven't save the logs and the enviroment is
> >>unavailable now.
> >
> >Well, please report back if you can reproduce the issue with current
> >upstream.
> >
> >Regards,
> >Martin
> >
> >
> 
> -- 
> Best Regard,
> Chongyun Wu