# Argument why (b) might in fact a problem: "disk should be detected as new, and not mapped onto the old paths/devices"
Obviously one could just say "have a static LUN Id plan and don't map back the old LUN, but that is evasive. In a perfect world something in kernel/udev/multipath would recognize it is a new thing. I agree that if you "map a different / new disk to the same lun" things should not totally break as you reported. I'd have expected that it would detect e.g. a UUID and only do so if these match. Do in your case the UUIDs also stay the same when you map a new disk under the same LUN? In my case (adding back the same disk under the same LUN) nothing changed. For example sg_inq reports absolutely the same $ sudo sg_inq --id /dev/sdh VPD INQUIRY: Device Identification page Designation descriptor number 1, descriptor length: 20 designator_type: NAA, code_set: Binary associated with the Addressed logical unit NAA 6, IEEE Company_id: 0x5076 Vendor Specific Identifier: 0x306ffd6b6 Vendor Specific Identifier Extension: 0x240a [0x6005076306ffd6b6000000000000240a] Designation descriptor number 2, descriptor length: 8 designator_type: Relative target port, code_set: Binary associated with the Target port Relative target port: 0x130 Designation descriptor number 3, descriptor length: 8 designator_type: Target port group, code_set: Binary associated with the Target port Target port group: 0x0 Be careful as there are plenty of UUIDs. The one of the FC/SCSI layer (sg_inq). Then there could be some below on GPT and on Filesystem. But IMHO multipath works "below" that and most likely only considers the ID of the FC/SCSI layer. In my test my LUN was totally empty, so I had no Partition/FS UUID at all. If your SCSI/FC UUID does not change, then I think this is mis-usage/mis-expectation. I'd be unsure what kernel/udev/multipass should do different. But if your UUID changes, then IMHO it should work. But I wonder if "appearance of a different disk in place of a missing one" was ever considered in mutlipath. I'd ask you to start a discussion upstream [1][2] for "what to expect" and "how to handle" that case. Please report a link to the discussion here and let us know of the outcome. No matter if it will be: 1. a different config (then everyone tracking this can benefit) 2. a patch we can fix the package(s) with 3. a lessons learned about what to expect from which component (then everyone tracking this can still benefit) [1]: https://www.redhat.com/mailman/listinfo/dm-devel [2]: https://github.com/opensvc/multipath-tools/issues ** Changed in: multipath-tools (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1911999 Title: faulty paths are not removed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1911999/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs