From: Martin Wilck <martin.wilck@suse.com>
To: "wucy11@chinatelecom.cn" <wucy11@chinatelecom.cn>,
"bmarzins@redhat.com" <bmarzins@redhat.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [dm-devel] [PATCH 2/2] multipathd: add recheck_wwid_time option to verify the path wwid
Date: Fri, 19 Feb 2021 10:46:06 +0000 [thread overview]
Message-ID: <7fe1a67f01849cb514f4ce3130715ac6f5d7709f.camel@suse.com> (raw)
In-Reply-To: <e930e111-d98d-bae2-baad-501c2c591d02@chinatelecom.cn>
On Thu, 2021-02-18 at 11:22 +0800, Chongyun Wu wrote:
> >
> > I wasn't aware of multiple affected users. I saw Chongyun's post
> > and it
> > looked to me as if this had happend once, likely in his
> > organization.
> > It wasn't even clear to me whether production data were affected.
> >
> Had customers have made incorrect storage back-end operations during
> the
> expansion process, which has caused the destruction of customer data,
> which
> cannot be repaired using any tools. And I reproduce it in our lab
> too.
> Customers definitely hope that multipath-tools can probide protection
> in
> this case, becuase if it is important custmer data storage in the
> LUN, the
> loss will be great.
I understand that. My concern was that it's still just quite a weak
protection, because it depends on the check time interval being short
enough to catch the change. So in a way, this pretends to offer safety
that doesn't truly exist. If the user assigns the wrong WWID 30s after
taking the LUN offline, all fine; if she is quicker (or has the process
automated / scripted), data corruption still occurs.
And of course, there are general limits to which extent software can
avoid user mistakes.
However, I trust your and Ben's judegement that by checking this in a
suitably short time span, the issues your customers have had would have
been avoided, and I'm not going to oppose the patch on these grounds.
Martin
--
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg GF: Felix Imendörffer
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-02-19 10:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 5:19 [dm-devel] [PATCH 0/2] Handle remapped LUNs better Benjamin Marzinski
2021-02-09 5:19 ` [dm-devel] [PATCH 1/2] libmultipath: fix use-after-free in uev_add_path Benjamin Marzinski
2021-02-09 20:57 ` Martin Wilck
2021-02-09 5:19 ` [dm-devel] [PATCH 2/2] multipathd: add recheck_wwid_time option to verify the path wwid Benjamin Marzinski
2021-02-09 22:19 ` Martin Wilck
2021-02-10 18:09 ` Benjamin Block
2021-02-10 19:57 ` Martin Wilck
2021-02-11 11:25 ` Benjamin Block
2021-02-11 4:48 ` Benjamin Marzinski
2021-02-11 12:14 ` Martin Wilck
2021-02-18 3:22 ` Chongyun Wu
2021-02-19 10:46 ` Martin Wilck [this message]
2021-02-27 6:02 ` Benjamin Marzinski
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=7fe1a67f01849cb514f4ce3130715ac6f5d7709f.camel@suse.com \
--to=martin.wilck@suse.com \
--cc=bmarzins@redhat.com \
--cc=dm-devel@redhat.com \
--cc=wucy11@chinatelecom.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).