lpfc_nodev_tmo

The main issue is native multipathing waits (as does PowerPath) until being told by the host that the device is not accessible. It relies on the scsi timeout, then the lpfc timeout. Where this can become an issue is that while it will eventually failover, it causes the host applications to wait on IO for an additional 20 seconds. Applications may not be able to survive this long of a wait. This also can cause issues when doing things like NDU upgrades of storage.

Per the emulex host connectivity guide, it is a required hba setting:

https://support.emc.com/docu6349_Host-Connectivity-with-Emulex-Fibre-Channel-Host-Bus-Adapters-%28HBAs%29-and-Fibre-Channel-over-Ethernet-Converged-Network-Adapters-%28CNAs%29-for-the-Linux-Environments.pdf

On page 88 see:

“* If EMC PowerPath,® Veritas DMP, or Linux native multipath (DM-MPIO) is installed, lpfc_nodev_tmo must be set to 10”

This indicates that the value must be set to 10. 

(Note there is a slight typo in the doc where P for PowerPath is in front of EMC which I have corrected below.)

modinfo lpfc | grep devloss

parm: lpfc_devloss_tmo:Seconds driver will hold I/O waiting for a device to come back (int)

modinfo lpfc | grep nodev

parm: lpfc_nodev_tmo:Seconds driver will hold I/O waiting for a device to come back (int)

Thanks. Follow-up question. When an HBA nodev timeout is actually reached, is that the mechanism that triggers path failover within powerpath or does powerpath have its own internal timeout for nodev? 

PowerPath doesn't have any timeout setting of its own. So when HBA nodev timeout is reached (and that is when PowerPath gets the notification from HBA driver), PowerPath would immediately fail the corresponding path.