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.
In particular, I wonder what happens if when "unmapping LUN1 and LUN2
in storage". I would expect that this would cause "remove" uevents, and
multipathd would set these devices in INIT_REMOVED state. That should
make multipathd realize that the path WWID changed when the path
reappears.
The issue is caused by wrong opertion in storage backend, it is very easy
to be reproduced by the metioned steps. There are no remove event sometimes
(maybe manual operation have differrent time windows), in this situation the
INIT_REMOVED state prodection might not been involved.
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.
Martin
--
Best Regard,
Chongyun Wu
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
