Thank you very much Ben and your pathset based on my patch looks good.
On 2021/2/9 12:50, Benjamin Marzinski wrote:
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@xxxxxxxxxxxxxxx>
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
--
Best Regard,
Chongyun Wu
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
