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): udev-039-10.29.el4 device-mapper-multipath-0.4.5-35.el4 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.
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.
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.
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. http://rhn.redhat.com/errata/RHBA-2011-0243.html