Bug 508833 - [NetApp 5.5 feat] Add support for setting dev_loss_tmo and fast_io_fail_tmo in /etc/multipath.conf
[NetApp 5.5 feat] Add support for setting dev_loss_tmo and fast_io_fail_tmo i...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
5.5
All Linux
high Severity high
: alpha
: 5.5
Assigned To: Ben Marzinski
Cluster QE
: FutureFeature, OtherQA
Depends On:
Blocks: 509443 518983 585225
  Show dependency treegraph
 
Reported: 2009-06-30 03:02 EDT by Tanvi
Modified: 2012-08-27 12:51 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 518983 (view as bug list)
Environment:
Last Closed: 2009-10-07 11:01:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tanvi 2009-06-30 03:02:07 EDT
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 05:56:01 EDT
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-06-30 22:51:09 EDT
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 08:18:25 EDT
(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 15:28:05 EDT
(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 16:49:51 EDT
(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-02 20:37:32 EDT
I already opened one. bz #509443
Comment 7 Daniel Riek 2009-10-07 10:47:08 EDT
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 Product and Program Management 2009-10-07 11:01:46 EDT
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request.

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