Red Hat Bugzilla – Bug 215975
kernel dm: application visible I/O errors with dm-multipath and queue_if_no_path when adding new path
Last modified: 2010-01-11 21:36:20 EST
noflush feature has been included in kernel and device-mapper,
but it has not been included in device-mapper-multipath.
So I cloned the Bugzilla for device-mapper-multipath.
+++ This bug was initially created as a clone of Bug #169302 +++
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.
-- Additional comment from firstname.lastname@example.org on 2005-10-03 18:14 EST --
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
-- Additional comment from email@example.com on 2006-01-09 10:26 EST --
This has been moved to being proposed for RHEL4 U4.
-- Additional comment from firstname.lastname@example.org on 2006-03-03 13:05 EST --
*** Bug 180437 has been marked as a duplicate of this bug. ***
-- Additional comment from email@example.com on 2006-03-15 12:09 EST --
Will be tricky to do this without affecting kABI - may have to wait until RHEL5.
-- Additional comment from firstname.lastname@example.org on 2006-03-16 10:36 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)
* < 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.
-- Additional comment from email@example.com on 2006-04-18 16:37 EST --
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
-- Additional comment from firstname.lastname@example.org on 2006-06-26 12:02 EST --
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?
-- Additional comment from email@example.com on 2006-10-10 21:50 EST --
-- Additional comment from firstname.lastname@example.org on 2006-10-30 10:57 EST --
Did the device-mapper and device-mapper-multipath changes get in as well.
There's nothing really obvious in the changelogs to indicate.
Oops. I missed this one. This was fix in the
Looks like this is already in RHEL5 beta per comment #2 above.
Escalating as an exception for management concurrence since it doesn't have any
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Devel ACK - Already in the build
device-mapper-multipath-0.4.7-6.el5 included in the 20061218.1 trees.