multipath: multipathd doesn't remove path devies timely, and orphan paths can prevent a multipath device creation later
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
os-brick |
Fix Released
|
Undecided
|
Takashi Kajinami |
Bug Description
This issue was initially reported in the following downstream bug.
https:/
We noticed that after hard rebooting an instance, sometimes the instance uses a single iscsi device instead of mutlipath device.
We confirmed that there are no errors or problems with iscsi device attachment but mutlipath device(dm-X) is not created even though "multipathd add" command succeeds, and os-brick decides to use a single path device because dm-X is not available.
After investigation and discussion with engineers covering multipathd, we found the following situation.
- Recent multipathd delays path removal when it receives burst of udev events.
- When os-brick detaches a multipath volume, it flushes a multipath device then removes the path devices directly in a short time. This is likely to cause "burst" of udev events
- Multipathd delays path removal, but volume attachment process started very shortly. A multipath device is again created but because old orphan paths are not removed at this moment multipathd rejects to create a multipath device.
Because os-brick requires very timely device removal, it should not rely on multipathd to remove device paths based on udev events but explicitly request to remove paths when detaching a device.
Changed in os-brick: | |
status: | New → In Progress |
A fix has been proposed here: https:/ /review. opendev. org/c/openstack /os-brick/ +/785818