Ubuntu

multipath flush always returns 1

Reported by Adam Guthrie on 2010-09-17
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
multipath-tools (Ubuntu)
Low
Peter Petrakis
Lucid
High
Unassigned
Maverick
High
Unassigned
Natty
High
Unassigned

Bug Description

Binary package hint: multipath-tools

multipath -f devicename or multipath -F alway return 1

Fixed upstream, patch attached.

Adam Guthrie (therigu) wrote :
Chuck Short (zulcss) wrote :

Thanks which version are you using?

chuck

Changed in multipath-tools (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for multipath-tools (Ubuntu) because there has been no activity for 60 days.]

Changed in multipath-tools (Ubuntu):
status: Incomplete → Expired
Serge Hallyn (serge-hallyn) wrote :

Adam,

thanks very much for the bug report and the patch.

Marking this Triaged as it has been confirmed elsewhere.

Changed in multipath-tools (Ubuntu):
status: Expired → Triaged
assignee: nobody → Peter Petrakis (peter-petrakis)
status: Triaged → Fix Released
Changed in multipath-tools (Ubuntu Lucid):
status: New → Incomplete
status: Incomplete → Triaged
Changed in multipath-tools (Ubuntu Maverick):
status: New → Triaged
Changed in multipath-tools (Ubuntu Natty):
status: New → Triaged
Changed in multipath-tools (Ubuntu Lucid):
importance: Undecided → High
Changed in multipath-tools (Ubuntu Maverick):
importance: Undecided → High
Changed in multipath-tools (Ubuntu Natty):
importance: Undecided → High
Serge Hallyn (serge-hallyn) wrote :

Per comment from Peter, this can actually cause a system crash, so marking this high priority.

dann frazier (dannf) wrote :

I can easily reproduce this problem w/ natty's multipath-tools and can verify that the above fix works for me. I should be able to test an SRU if desired.

Peter Petrakis (peter-petrakis) wrote :

It's an indirect crash, if we're script driven, since the output is always
1, the user decided that the return value meant nothing and that
removing the actual path member was OK. Instead a crash occurred.

Peter Petrakis (peter-petrakis) wrote :

debs available for testing from ppa:peter-petrakis/storage for
all affected distributions. Please test.

root@kickseed:~# multipath -f 222d8000155636433
libdevmapper: libdm-common.c(489): Removed /dev/mapper/222d8000155636433
root@kickseed:~# echo $?
0
root@kickseed:~# lsb_release -r
Release: 10.04

apt-cache policy multipath-tools | grep Insta
  Installed: 0.4.8-14ubuntu4.10.04.2.1

Peter Petrakis (peter-petrakis) wrote :

SRU Justification:
 * During development where a customer is aiming to automate storage
 provisioning that includes a multipath component. Politely tearing
 down the dm table before physically removing the device is part of
 best practices for removing devices at runtime. Since multipath -f/-F
 always returns 1, the customer assumed that the return code was irrelevant
 and continued with device removal. In the cases where DM really wasn't
 finished flushing the outstanding I/O, a kernel crash occurred, since
 the customer essentially tore the backing store out from under multipath
 while there was pending I/O. All based on the faulty return value of
 multipath -f/-F.

 * The patch is pulled from upstream, with only minor modification to
 suit our older codebase. We're simply forwarding the return value
 from this dm table operation instead of dropping it.

 * Regression possibility is low, and the corrected return behavior
 may prevent further unnecessary kernel triage in the future.

 * TEST CASE: Make a multipath device busy, flush it, and immediately
 remove it, physically.

 * Inadvertent regression potential: None, if anything it'll improve
 best practices.

James Page (james-page) wrote :

Hi Peter

Thanks very much for documenting the SRU justification and proposing branches for lucid, natty and maverick.

Unfortunately there is already a SRU in -proposed for multipath-tools (see bug 789229) so we need to let this complete SRU process to -updates for these three releases before uploading your proposed branches.

You will need to update each of your proposed branches with the changes from -updates once accepted and revise the debian/changelog version numbers as below:

 Natty: 0.4.8-14ubuntu10.3
 Maverick: 0.4.8-14ubuntu4.10.10.4
 Lucid: 0.4.8-14ubuntu4.10.04.4

Please can you also make sure that the branches target -proposed in the changelog, i.e. natty-proposed, instead of the standard 'natty' release pocket - this will make sure it gets into the right part of the archive for SRU verification.

I'm going to mark all three merge proposals as 'Needs Fixing' for the time being as they all need to be updated.

You can find more detail on the SRU process here - https://wiki.ubuntu.com/StableReleaseUpdates#Procedure.

Thanks again

Hi James,

Thanks for the feedback. Will track bug 789229 and rebase/propose
accordingly.

JC Hulce (soaringsky) wrote :

This bug affects Ubuntu 10.10, Maverick Meerkat. Maverick has reached end-of-life and is no longer supported, so I am closing the bugtask for Maverick. Please upgrade to a newer version of Ubuntu.
More information here: https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/000158.html

Changed in multipath-tools (Ubuntu Maverick):
status: Triaged → Invalid
dino99 (9d9) wrote :
Changed in multipath-tools (Ubuntu Natty):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers