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@xxxxxxxx>, 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@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel