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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
