Red Hat Bugzilla – Bug 169302
kernel dm: application visible I/O errors with dm-multipath and queue_if_no_path when adding new path
Last modified: 2010-10-21 23:26:02 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
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
Application in step #4 receives I/O errors
Application in step #4 _not_ to receive I/O errors
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.
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
This has been moved to being proposed for RHEL4 U4.
*** Bug 180437 has been marked as a duplicate of this bug. ***
Will be tricky to do this without affecting kABI - may have to wait until RHEL5.
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)
* < 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
* 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.
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
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?
Did the device-mapper and device-mapper-multipath changes get in as well.
There's nothing really obvious in the changelogs to indicate.