Bug 694602 - [6.2 FEAT] Change in multipath.conf file for RSSM
[6.2 FEAT] Change in multipath.conf file for RSSM
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
6.2
All All
high Severity high
: beta
: 6.2
Assigned To: Ben Marzinski
Gris Ge
: FutureFeature, OtherQA
Depends On:
Blocks: 659725 638197 697866
  Show dependency treegraph
 
Reported: 2011-04-07 14:13 EDT by IBM Bug Proxy
Modified: 2011-12-12 13:11 EST (History)
13 users (show)

See Also:
Fixed In Version: device-mapper-multipath-0.4.9-42.el6
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-06 13:07:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
IBM Linux Technology Center 71340 None None None Never

  None (edit)
Description IBM Bug Proxy 2011-04-07 14:13:12 EDT
1. Feature Overview:
Feature Id: [71340]
a. Name of Feature: [6.2 FEAT] Change in multipath.conf file for RSSM
b. Feature Description
Storage currently has the IBM RAIDed SAS Switch as an option for the BladeCenter - S chassis.  Up to
now we have been providing to our customers a modified multipath.conf fill with settings to use when
running with the RSSM.  Would like to see is if we could get the settings rolled up into the disro
as defaults: 

 device {
        vendor                  "IBM"
        product                 "1820N00"
        getuid_callout          "/lib/udev/scsi_id --whitelisted --device=/dev/%n"
        hardware_handler        "0"
        path_selector           "round-robin 0"
        path_grouping_policy    group_by_prio
        failback                immediate
        rr_weight               uniform
        rr_min_io               100
        path_checker            tur
        prio                    alua
        polling_interval        30
        no_path_retry           queue
    }


2. Feature Details:
Sponsor: LTC
Architectures:  ppc64, x86, x86_64, 
Arch Specificity: purely common code
Affects Kernel Modules: No
Delivery Mechanism: LDP Deliverable
Category: other
Request Type: Configuration/Build Change
d. Upstream Acceptance: No Code Required
Sponsor Priority P3
f. Severity: high
IBM Confidential: No
Code Contribution: no
g. Component Version Target: ---

3. Business Case
This would make the environment much easier on our customers.

4. Primary contact at Red Hat:
John Jarvis, jjarvis@redhat.com

5. Primary contacts at Partner:
Project Management Contact:
Stephanie A. Glass, sglass@us.ibm.com

Technical contact(s):
Brent Yardley, yardleyb@us.ibm.com
Comment 2 RHEL Product and Program Management 2011-04-07 14:24:40 EDT
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 3 Ales Kozumplik 2011-04-08 02:43:04 EDT
(In reply to comment #0)
> running with the RSSM.  Would like to see is if we could get the settings
> rolled up into the disro
> as defaults: 
> 
>  device {
>         vendor                  "IBM"
>         product                 "1820N00"
>         getuid_callout          "/lib/udev/scsi_id --whitelisted
> --device=/dev/%n"
>         hardware_handler        "0"
>         path_selector           "round-robin 0"
>         path_grouping_policy    group_by_prio
>         failback                immediate
>         rr_weight               uniform
>         rr_min_io               100
>         path_checker            tur
>         prio                    alua
>         polling_interval        30
>         no_path_retry           queue
>     }

a) Do you want to always have this in every multipath.conf anaconda generates or only when the RSSM is detected? 

b) How do we detect RSSM?
Comment 5 IBM Bug Proxy 2011-04-08 11:11:49 EDT
------- Comment From yardleyb@us.ibm.com 2011-04-08 11:00 EDT-------
(In reply to comment #5)
> (In reply to comment #0)
> > running with the RSSM.  Would like to see is if we could get the settings
> > rolled up into the disro
> > as defaults:
> >
> >  device {
> >         vendor                  "IBM"
> >         product                 "1820N00"
> >         getuid_callout          "/lib/udev/scsi_id --whitelisted
> > --device=/dev/%n"
> >         hardware_handler        "0"
> >         path_selector           "round-robin 0"
> >         path_grouping_policy    group_by_prio
> >         failback                immediate
> >         rr_weight               uniform
> >         rr_min_io               100
> >         path_checker            tur
> >         prio                    alua
> >         polling_interval        30
> >         no_path_retry           queue
> >     }
> a) Do you want to always have this in every multipath.conf anaconda generates or only when the RSSM is detected?

If it makes sense, from an ease of implementation perspective to include it always, then lets do that.

>
> b) How do we detect RSSM?

RSSM Is a SAS based device, it has a SCSI product ID of 1820N00 and product vendor of IBM.  It's LUNs would be discovered when a SAS HBA driver is loaded and RSSM is attached.
Comment 6 Ben Marzinski 2011-04-08 12:11:33 EDT
Yeah, this is just adding a new device to the list of devices that multipath autoconfigures.  We do this sort of thing all the time, to make life easier for everyone involved.

In the future, if you have any devices you want device-mapper-multipath to autoconfigure, you should file the bug against it, instead of anaconda.
Comment 7 John Jarvis 2011-04-19 23:02:11 EDT
IBM is signed up to test and provide feedback, setting OtherQA.
Comment 10 Ben Marzinski 2011-06-30 01:41:45 EDT
configuation added
Comment 11 John Jarvis 2011-06-30 11:37:36 EDT
This enhancement request was evaluated by the full Red Hat Enterprise Linux
team for inclusion in a Red Hat Enterprise Linux minor release.   As a result
of this evaluation, Red Hat has tentatively approved inclusion of this feature
in the next Red Hat Enterprise Linux Update minor release.   While it is a goal
to include this enhancement in the next minor release of Red Hat Enterprise
Linux, the enhancement is not yet committed for inclusion in the next minor
release pending the next phase of actual code integration and successful Red
Hat and partner testing.
Comment 13 Gris Ge 2011-09-21 03:08:58 EDT
Ben,

IBM was requesting "polling_interval 30" but this entry is missed from multipathd -k'show config'

The default setting for polling_interval is 5. (device-mapper-multipath-0.4.9-43.el6.x86_64)

Does this expect results?
Comment 14 Gris Ge 2011-09-21 03:16:19 EDT
Another concern, 
As Bug #419581 mentioned, "no_path_retry queue" will cause OS cannot shutdown when all path down.

The default "queue_without_daemon" is "yes" which will not disable queue when daemon shutdown.

Should we change this configuration to "no_path_retry N"?
Comment 15 Ben Marzinski 2011-09-21 15:29:34 EDT
About the "polling_interval 30": Good catch.  Somehow I missed that line in my patch.

About the "no_path_retry queue": No. Other configurations do this as well. Some people really don't want to ever fail the IO back, unless the sysadmin manually
does it.  For the default configs, we simply honor what the vendors give us, which is the configuration that they tested.  It makes more sense to fix the problem by changing the "queue_without_daemon" default, which should be possible.  The only issue is that I need to add a multipathd command to override the queue_without_daemon option, that can be used when restarting multipathd.  That way, if someone does a

# service multipathd restart

With a queuing multipath device with no valid paths, they won't suddenly start seeing IOs getting failed, when they wouldn't before.

I'll include a fix for the polling interval when I respin the package to fix the other crash you found for 697386
Comment 16 Gris Ge 2011-09-21 23:10:12 EDT
A wild idea about the queue issue, can we store/move the queued I/O to the kernel memory of dm-multipath module? In that case, restart daemon don't fail I/O and read it back to queue. When OS shutdown, it will got cleaned without any option.

Previously there is a patch for saving dev_loss_tmo value after link down, this idea is coming from that patch.

Forgive me if this is a silly idea as I don't know the SCSI mid layer at all.
I am keep studying to be a good storage-qe.
Comment 17 Ben Marzinski 2011-09-21 23:52:34 EDT
I wasn't thinking before.  You can't set the polling_interval on a per-device basis.  You can only set it for all of multipathd. That's why I didn't add it.
Comment 18 Gris Ge 2011-09-23 01:50:33 EDT
I see. IBM should be informed for this changed.

Then, you have my VERIFY.
Comment 19 errata-xmlrpc 2011-12-06 13:07:13 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1527.html

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