Bug 169302 - kernel dm: application visible I/O errors with dm-multipath and queue_if_no_path when adding new path
kernel dm: application visible I/O errors with dm-multipath and queue_if_no_p...
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
: 180437 (view as bug list)
Depends On:
Blocks: 182355 188682
  Show dependency treegraph
Reported: 2005-09-26 15:27 EDT by Dave Wysochanski
Modified: 2010-10-21 23:26 EDT (History)
20 users (show)

See Also:
Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-16 10:20:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dave Wysochanski 2005-09-26 15:27:45 EDT
Description of problem:
If you lose all paths to a device, queue_if_no_path is set, and then you try to
add a new path to the same device via running multipath tool again, you'll get
I/O errors visible to the application.  This has been discussed before, and
was discussed in the 9/22/2005 multipath concall, with Alasdair confirming that
this was the expected behavior as of today, and that there were a few possible
approaches to solving this problem.

Version-Release number of selected component (if applicable):
- kernel: 2.6.9-22.ELsmp
- device-mapper-1.01.04-1.0.RHEL4
- device-mapper-multipath-0.4.5-5.2.RHEL4
- udev-039-10.11.EL4
- hotplug-2004_04_01-7.6
- lvm2-2.01.14-1.0.RHEL4

How reproducible:
Every time

Steps to Reproduce:
1. Map one LUN, with 2 paths to the LUN, and queue_if_no_path set, and start I/O
running over the LUN
2. Pull cables (or make other disruption) so that both paths go down and note
that I/O gets queued
3. Add a 3rd path to the same LUN, and run multipath again to pick up the new path
4. Observe that application running I/O over the LUN gets I/O errors  

Actual results:
Application in step #4 receives I/O errors

Expected results:
Application in step #4 _not_ to receive I/O errors

Additional info:
Note that if you don't lose all paths, you can add a new path in via the
multipath tool and not get application visible I/O errors.
Comment 1 Alasdair Kergon 2005-10-03 18:14:03 EDT
  It needs to be possible for a dm table to pass context information to its

  The queueing needs to happen at the dm level rather than with the multipath
Comment 9 Andrius Benokraitis 2006-01-09 10:26:12 EST
This has been moved to being proposed for RHEL4 U4.
Comment 10 Alasdair Kergon 2006-03-03 13:05:50 EST
*** Bug 180437 has been marked as a duplicate of this bug. ***
Comment 11 Alasdair Kergon 2006-03-15 12:09:13 EST
Will be tricky to do this without affecting kABI - may have to wait until RHEL5.
Comment 12 Jun'ichi NOMURA 2006-03-16 10:36:50 EST
While there could be different approaches,
NEC have proposed a solution by pushing back target bios to dm core.

We would appreciate feedbacks in dm-devel and are happy to discuss
other possible approaches.

Our proposal doesn't change exported structure and exported symbols.
Only change it affects kABI (API, actually) is that the extention
of return values of target's map() and endio().

(Please read the followings like diff output)

map() returns:
  * < 0: error
  * = 0: The target will handle the io by resubmitting it later
- * > 0: simple remap complete
+ * = 1: simple remap complete
+ * = 2: The target wants to push back the io

endio() returns:
  * 0   : ended successfully
  * 1   : for some reason the io has still not completed (eg,
  *       multipath target might want to requeue a failed io).
+ * 2   : The target wants to push back the io

No in-box dm target drivers are affected by them.
But we cannot deny possible existence of out-box target driver
which use positive values for other purpose.

Disadvantage of this approach may be the necessity of modifying
target drivers to activate this feature.
Comment 14 David Lawrence 2006-04-18 16:37:37 EDT
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
Comment 18 Andrius Benokraitis 2006-06-26 12:02:13 EDT
Moving this bug to be proposed for RHEL5 GA based on comments from Alasdar, and
then look at 4.5 afterwards. How big a deal is this for 4.5 for NetApp? 
Comment 28 Don Zickus 2006-10-10 21:50:24 EDT
in kernel-2.6.18-1.2725.el5
Comment 29 Jay Turner 2006-10-30 10:57:43 EST
Did the device-mapper and device-mapper-multipath changes get in as well. 
There's nothing really obvious in the changelogs to indicate.

Note You need to log in before you can comment on or make changes to this bug.