fast_io_fail_tmo is a timeout value of the HBA and not of PowerPath.  It determines how long SCSI will wait after an issue is detected on the remote port before failing an IO.  From PowerPath for Linux 6.0.0, there are two timeout parameters that can be configured in PowerPath.  path_retry_timeout: This is set to 5 seconds by default.  When PowerPath is active, it uses this value to change the fast_io_fail_tmo of the HBAs.  Thereby SCSI will fail the IOs faster to us and PowerPath can retry that IO on another active alive path.  all_paths_dead_retry_timeout:  This is set to 'default' by default.   By 'default' it means it will take the 'dev_loss_tmo' value of the HBA and it will keep retying the IOs for that long AFTER an all paths are marked as dead to a LUN.  if any of the paths come back alive before this timeout, then the IO will be retried on that path and will succeed.  Instead of 'default' it can be set to any user desired value.  In case, it is set to any other value, then care must be taken to set it back to 'default' or atleast 30 seconds before a Symm NDU is done.  Because in case of Symm NDU, all the paths can briefly go dead and a low all_paths_dead_rety_timeout may mean that the IO is failed back up before any of the paths can become alive.  Information on both these commands and their usage can be found in PowerPath 6.x CLI and message reference guide.
Question for anyone with linux hosts in multipathing and VMAX storage. The default setting for lpfc_nodev_tmo is 30 seconds. EMC recommends 10 seconds if powerpath is in use. Same for VxDMP and MPIO. Obviously, lowering this to 10 seconds will result in a faster path failover but is there any real issue with leaving this at default other than slightly slower path failovers? .
lpfc_nodev_tmo