<html><head></head><body><div><br></div><div><span></span></div><div><br></div><div>On Mon, 2021-04-26 at 13:16 +0000, Martin Wilck wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Mon, 2021-04-26 at 13:14 +0200, Ulrich Windl wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div></blockquote><div><br></div><div>While we're at it, I'd like to mention another issue: WWID changes.<br></div><div><br></div><div>This is a big problem for multipathd. The gist is that the device<br></div><div>identification attributes in sysfs only change after rescanning the<br></div><div>device. Thus if a user changes LUN assignments on a storage system,<br></div><div>it can happen that a direct INQUIRY returns a different WWID as in<br></div><div>sysfs, which is fatal. If we plan to rely more on sysfs for device<br></div><div>identification in the future, the problem gets worse. <br></div></blockquote><div><br></div><div>I think many devices rely on the fact that they are identified by<br></div><div>Vendor/model/serial_nr, because in most professional SAN storage<br></div><div>systems you<br></div><div>can pre-set the serial number to a custom value; so if you want a new<br></div><div>disk<br></div><div>(maybe a snapshot) to be compatible with the old one, just assign the<br></div><div>same<br></div><div>serial number. I guess that's the idea behind.<br></div></blockquote><div><br></div><div>What you are saying sounds dangerous to me. If a snapshot has the same<br></div><div>WWID as the device it's a snapshot of, it must not be exposed to any<br></div><div>host(s) at the same time with its origin, otherwise the host may<br></div><div>happily combine it with the origin into one multipath map, and data<br></div><div>corruption will almost certainly result. <br></div><div><br></div><div>My argument is about how the host is supposed to deal with a WWID<br></div><div>change if it happens. Here, "WWID change" means that a given H:C:T:L<br></div><div>suddenly exposes different device designators than it used to, while<br></div><div>this device is in use by a host. Here, too, data corruption is<br></div><div>imminent, and can happen in a blink of an eye. To avoid this, several<br></div><div>things are needed:<br></div><div><br></div><div> 1) the host needs to get notified about the change (likely by an UA of<br></div><div>some sort)<br></div><div> 2) the kernel needs to react to the notification immediately, e.g. by<br></div><div>blocking IO to the device,<br></div><div> 3) userspace tooling such as udev or multipathd need to figure out how<br></div><div>to how to deal with the situation cleanly, and eventually unblock it.<br></div><div><br></div><div>Wrt 1), we can only hope that it's the case. But 2) and 3) need work,<br></div><div>afaics.<br></div><div><br></div></blockquote><div>In my view the WWID should never change. If a snapshot is created it should either obtain a new WWID. An example out of a Hitachi array is</div><div><br></div><div>Device Identification VPD page:</div><div> Addressed logical unit:</div><div> designator type: T10 vendor identification, code set: ASCII</div><div> vendor id: HITACHI </div><div> vendor specific: 50403B050709</div><div> designator type: NAA, code set: Binary</div><div> 0x60060e80123b050050403b050000<b><u>0709</u></b></div><div><br></div><div>The majority of the naa wwid is tied to the storage subsystem and identifies the vendor oui, model, serial etc. The last 4 in this example indicate the LDEV ID (Sorry mainframe heritage here..). When a snapshot is taken these 4 will change as a new LDEV ID is assigned to the snapshot. This sort of behaviour should be consistent across all storage vendors imho.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Martin<br></div><div><br></div></blockquote></body></html>