On Mon, 2021-04-26 at 13:14 +0200, Ulrich Windl wrote: > > > > > > > While we're at it, I'd like to mention another issue: WWID changes. > > > > This is a big problem for multipathd. The gist is that the device > > identification attributes in sysfs only change after rescanning the > > device. Thus if a user changes LUN assignments on a storage system, > > it can happen that a direct INQUIRY returns a different WWID as in > > sysfs, which is fatal. If we plan to rely more on sysfs for device > > identification in the future, the problem gets worse. > > I think many devices rely on the fact that they are identified by > Vendor/model/serial_nr, because in most professional SAN storage > systems you > can pre-set the serial number to a custom value; so if you want a new > disk > (maybe a snapshot) to be compatible with the old one, just assign the > same > serial number. I guess that's the idea behind. What you are saying sounds dangerous to me. If a snapshot has the same WWID as the device it's a snapshot of, it must not be exposed to any host(s) at the same time with its origin, otherwise the host may happily combine it with the origin into one multipath map, and data corruption will almost certainly result. My argument is about how the host is supposed to deal with a WWID change if it happens. Here, "WWID change" means that a given H:C:T:L suddenly exposes different device designators than it used to, while this device is in use by a host. Here, too, data corruption is imminent, and can happen in a blink of an eye. To avoid this, several things are needed: 1) the host needs to get notified about the change (likely by an UA of some sort) 2) the kernel needs to react to the notification immediately, e.g. by blocking IO to the device, 3) userspace tooling such as udev or multipathd need to figure out how to how to deal with the situation cleanly, and eventually unblock it. Wrt 1), we can only hope that it's the case. But 2) and 3) need work, afaics. 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
