Bug 511034 - [NetApp 4.9 bug] Dm-multipath occasionally fails to configure devices when large no. of luns/paths are mapped to a RHEL 4.8 host
[NetApp 4.9 bug] Dm-multipath occasionally fails to configure devices when la...
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
All Linux
medium Severity medium
: rc
: 4.9
Assigned To: Ben Marzinski
Red Hat Kernel QE team
: OtherQA
Depends On:
Blocks: 626414
  Show dependency treegraph
Reported: 2009-07-13 07:51 EDT by Tanvi
Modified: 2011-02-16 09:24 EST (History)
19 users (show)

See Also:
Fixed In Version: device-mapper-multipath-0.4.5-40.el4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-16 09:24:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0243 normal SHIPPED_LIVE device-mapper-multipath bug fix and enhancement update 2011-02-15 11:34:54 EST

  None (edit)
Description Tanvi 2009-07-13 07:51:57 EDT
Description of problem:
It has been seen that on a RHEL4.8 machine, sometimes all the multipath maps don't get created automatically when large number of LUNs are discovered. When 512 iscsi LUNs (512 LUNs * 2 paths = 1024 devices) were mapped and discovered on the host, only 492 maps got created automatically. The remaining maps got created only after running "multipath" command. The issue was not seen when 256 LUNs (256 LUNs * 4 paths = 1024 devices) were mapped to the host.

Version-Release number of selected component (if applicable):

How reproducible:
Highly reproducible.

Steps to Reproduce:
1.Map 512 LUNs to the host
2.Rescan iscsi sessions using iscsi-rescan

Actual results:
multipath command is needed to create all the multipath maps

Expected results:
All the maps should get created automatically.
Comment 1 Ben Marzinski 2010-05-28 13:41:09 EDT
I haven't been able to recreate this myself, but my best guess is that it's a race between multipath and sysfs.  multipath can be invoked before all of the sysfs files are populated.  This will keep the paths from being included in any multipath map.  The easiest way to prove that this is the case is to look at the output of

# multipathd -k"show paths"

This should show all of the paths, however, some of them will be orphans.  If this isn't what you see, then there seems to be a problem with the uevents.  In this case, hopefully you can use the output in /var/log/messages to verify whether or not multipathd tried to add the path. If it never tried, then the problem is in udev.  If it did, then I can look into that.
Comment 3 Ben Marzinski 2010-10-27 23:39:08 EDT
Like RHEL5, multipath will now wait up to a minute for the necessary sysfs files to appear when creating a device.  However, if the /sys/block/<devname> directory doesn't exist, it will stop waiting early, since this will always exist by the time udev calls multipath.
Comment 5 errata-xmlrpc 2011-02-16 09:24:44 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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