Multipath not flushed when friendly names are enabled

Bug #1663925 reported by Gorka Eguileor on 2017-02-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
os-brick
Undecided
Gorka Eguileor

Bug Description

When we are using friendly names for multipath the multipaths are not getting flushed, which may lead to data loss on slow connections and multipath entries with no actual paths.

This happens in both iSCSI and FC connections, and it is due to the flush being requested on the WWN instead of the actual name of the device.

So when we are not using friendly names the WWN and the device name are the same and our call to multipath -f will successfully flush remaining data, but when we are using friendly names they will not match, and the call to multipath -f will silently fail (return code 0) and the flush will not actually go through. When the flush doesn't happen, if there is remaining data, then the multipath will stay once the individual paths have been removed.

Gorka Eguileor (gorka) on 2017-02-11
Changed in cinder:
assignee: nobody → Gorka Eguileor (gorka)
Gorka Eguileor (gorka) on 2017-02-11
affects: cinder → os-brick

Fix proposed to branch: master
Review: https://review.openstack.org/433102

Changed in os-brick:
status: New → In Progress

Reviewed: https://review.openstack.org/433102
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=c0640ce13727e97832049f1d68744e715c3fa031
Submitter: Jenkins
Branch: master

commit c0640ce13727e97832049f1d68744e715c3fa031
Author: Gorka Eguileor <email address hidden>
Date: Sat Feb 11 20:58:08 2017 +0100

    Fix multipath flush when using friendly names

    When we are using friendly names for multipath the multipaths are not
    getting flushed, which may lead to data loss on slow connections and
    multipath entries with no actual paths.

    This happens in both iSCSI and FC connections, and it is due to the
    flush being requested on the WWN instead of the actual name of the
    device.

    So when we are not using friendly names the WWN and the device name are
    the same and our call to multipath -f will successfully flush remaining
    data, but when we are using friendly names they will not match, and the
    call to multipath -f will silently fail (return code 0) and the flush
    will not actually go through. When the flush doesn't happen, if there is
    remaining data, then the multipath will stay once the individual paths
    have been removed.

    Closes-Bug: #1663925
    Change-Id: Ib93d945a5b5fca57bcac4e176d62d1412b95f2da

Changed in os-brick:
status: In Progress → Fix Released

Reviewed: https://review.openstack.org/445941
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=cbeb89933c57b9e9756c460fa07aab254b15078d
Submitter: Jenkins
Branch: stable/ocata

commit cbeb89933c57b9e9756c460fa07aab254b15078d
Author: Gorka Eguileor <email address hidden>
Date: Sat Feb 11 20:58:08 2017 +0100

    Fix multipath flush when using friendly names

    When we are using friendly names for multipath the multipaths are not
    getting flushed, which may lead to data loss on slow connections and
    multipath entries with no actual paths.

    This happens in both iSCSI and FC connections, and it is due to the
    flush being requested on the WWN instead of the actual name of the
    device.

    So when we are not using friendly names the WWN and the device name are
    the same and our call to multipath -f will successfully flush remaining
    data, but when we are using friendly names they will not match, and the
    call to multipath -f will silently fail (return code 0) and the flush
    will not actually go through. When the flush doesn't happen, if there is
    remaining data, then the multipath will stay once the individual paths
    have been removed.

    Closes-Bug: #1663925
    Change-Id: Ib93d945a5b5fca57bcac4e176d62d1412b95f2da
    (cherry picked from commit c0640ce13727e97832049f1d68744e715c3fa031)

tags: added: in-stable-ocata

This issue was fixed in the openstack/os-brick 1.12.0 release.

This issue was fixed in the openstack/os-brick 1.11.1 release.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers