Bug 508833

Summary: [NetApp 5.5 feat] Add support for setting dev_loss_tmo and fast_io_fail_tmo in /etc/multipath.conf
Product: Red Hat Enterprise Linux 5 Reporter: Tanvi <tanvi>
Component: device-mapper-multipathAssignee: Ben Marzinski <bmarzins>
Status: CLOSED WONTFIX QA Contact: Cluster QE <mspqa-list>
Severity: high Docs Contact:
Priority: high    
Version: 5.5CC: agk, andriusb, bmarzins, bmr, christophe.varoqui, coughlan, donhoover, dwysocha, edamato, egoggin, heinzm, junichi.nomura, kueda, lmb, marting, mbroz, mchristi, prockai, riek, tranlan, xdl-redhat-bugzilla
Target Milestone: alphaKeywords: FutureFeature, OtherQA
Target Release: 5.5   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 518983 (view as bug list) Environment:
Last Closed: 2009-10-07 15:01:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 509443, 518983, 585225    

Description Tanvi 2009-06-30 07:02:07 UTC
Description of problem:
Presently there is no way we can see all the multipath settings dynamically. We need to refer either /etc/multipath.conf or /usr/share/doc/device-mapper-multipath-0.4.7/multipath.conf.defaults file to know the settings being used by multipath. show config command available in interactive mode of multipathd does list some settings, but it does not show few settings such as polling_interval, dev_loss_tmo and fast_io_fail_tmo. Filing here as a feature request for RHEL 5.5.


Version-Release number of selected component (if applicable):
device-mapper-multipath-0.4.7-28.el5

Comment 1 Bryn M. Reeves 2009-06-30 09:56:01 UTC
dev_loss_tmo and fast_io_fail_tmo are properties of the HBA driver / FC remote ports (part of the FC transport class) not multipath settings per-se.

They are always available via sysfs, e.g.:

# find /sys/class/ -name "*_tmo"
/sys/class/fc_remote_ports/rport-5:0-1/fast_io_fail_tmo
/sys/class/fc_remote_ports/rport-5:0-1/dev_loss_tmo
/sys/class/fc_remote_ports/rport-5:0-0/fast_io_fail_tmo
/sys/class/fc_remote_ports/rport-5:0-0/dev_loss_tmo
/sys/class/fc_remote_ports/rport-4:0-1/fast_io_fail_tmo
/sys/class/fc_remote_ports/rport-4:0-1/dev_loss_tmo
/sys/class/fc_remote_ports/rport-4:0-0/fast_io_fail_tmo
/sys/class/fc_remote_ports/rport-4:0-0/dev_loss_tmo

# cat /sys/class/fc_remote_ports/rport-5:0-1/fast_io_fail_tmo
off
# cat /sys/class/fc_remote_ports/rport-5:0-1/dev_loss_tmo
16

I do see polling_interval reported in the output of "show config" as long as it is set to in the config file:

# grep polling /etc/multipath.conf 
	polling_interval        12

multipathd> show config
defaults {
	polling_interval 12
	no_path_retry fail
	user_friendly_names yes
}
[...]

Comment 2 Mike Christie 2009-07-01 02:51:09 UTC
It might be nice for multipath to set the dev_loss_tmo and fast_io_fail_tmo when mulitpath is used. You could have a multipath.conf setting. You would want fast_io_fail_tmo low (5 secs or maybe 3 or 2). If multipath sets those values then maybe it could display what was used?

I think it would also be good to have a generic fc or scsi tool to display the dev_loss_tmo and fast_io_fail for other cases/uses since as Bryn points out they are not specific to multipath.

Comment 3 Martin George 2009-07-02 12:18:25 UTC
(In reply to comment #1)
> 
> I do see polling_interval reported in the output of "show config" as long as it
> is set to in the config file:
> 

But is that the right approach? Ideally the 'show config' should display all the values in use irrespective of whether they are set in the multipath.conf or not. Only then would the command output be really helpful.


(In reply to comment #2)
> It might be nice for multipath to set the dev_loss_tmo and fast_io_fail_tmo
> when mulitpath is used. You could have a multipath.conf setting. You would want
> fast_io_fail_tmo low (5 secs or maybe 3 or 2). If multipath sets those values
> then maybe it could display what was used?
> 

Yes, that's what we had in mind. Dm-multipath could tweak dev_loss_tmo & fast_io_fail_tmo for optimum performance. So those settings showing up in the 'show config' output would actually be helpful.

Comment 4 Ben Marzinski 2009-07-02 19:28:05 UTC
(In reply to comment #3)
> 
> But is that the right approach? Ideally the 'show config' should display all
> the values in use irrespective of whether they are set in the multipath.conf or
> not. Only then would the command output be really helpful.
> 

No. That's a bug. Multipath should display all of the defined defaults, whether they are built-in or user defined.  Also, it should display all of the devices and multipaths values that are defined, even if they are set to the same thing as the defaults.  This way, you know whether or not changing that parameter in the defaults section will actually change it for that device/multipath.

So now there are two issues here. How about we keep this bugzilla as a feature request for adding support for setting dev_loss_tmo and fast_io_fail_tmo via
/etc/multipath.conf, and open a new bug for fixing show config to show all of
the config values correctly.

Comment 5 Martin George 2009-07-02 20:49:51 UTC
(In reply to comment #4)
> 
> So now there are two issues here. How about we keep this bugzilla as a feature
> request for adding support for setting dev_loss_tmo and fast_io_fail_tmo via
> /etc/multipath.conf, and open a new bug for fixing show config to show all of
> the config values correctly.  

Ok. Will open a new bugzilla then for tracking the 'show config' issue.

Comment 6 Ben Marzinski 2009-07-03 00:37:32 UTC
I already opened one. bz #509443

Comment 7 Daniel Riek 2009-10-07 14:47:08 UTC
This enhancement request was evaluated by Red Hat Product Management for inclusion a Red Hat Enterprise Linux minor update release.

Red Hat does not currently plan to provide this enhanced functionality in a Red Hat Enterprise Linux minor update for currently deployed products.

With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating enhancements for inclusion in minor updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.

For more information on Red Hat Enterprise Linux maintenance policies, please consult: http://www.redhat.com/security/updates/errata/

Red Hat values your feedback and will take this enhancement request into consideration for future major releases of Red Hat Enterprise Linux.

Comment 9 RHEL Program Management 2009-10-07 15:01:46 UTC
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request.