快速 I/O 失败和动态跟踪交互
尽管快速 I/O 失败和光纤通道 (FC) 设备的动态跟踪是不同技术的功能部件，然而启用其中一个在某些情况下可以更改另一个的解释。 以下表格显示带有以下设置的不同排列的 FC 驱动程序的行为：
| dyntrk | fc_err_recov | FC 驱动程序行为 |
|---|---|---|
| False | delayed_fail |
缺省设置。 这是先前版本的 AIX®中存在的旧行为。 如果设备的 SCSI 标识发生更改，那么 FC 驱动程序不会恢复，并且当远程存储端口和交换机之间发生链路丢失时， I/O 需要更长时间才能失败。 如果动态跟踪支持并不是必需的话，那么这将更多地在单通道情况下使用。 |
| False | fast_fail |
如果驱动程序从交换机处接收到 RSCN，这表明在远程存储端口和交换机之间的链接丧失。 在最初的 15 秒延迟之后，FC 驱动程序请求查看设备是否在光纤网上。 如果不在光纤网上，那么 I/O 由适配器清空。 如果设备仍然不在光纤网上，那么之后的重试或新的 I/O 会立即失败。 如果 FC 驱动程序检测到设备在光纤网上，但是 SCSI ID 已经更改，那么 FC 设备驱动程序那么不会恢复，并且 I/O 会由于 PERM 错误而失败。 |
| 是 | delayed_fail |
如果驱动程序从交换机处接收到 RSCN，这表明在远程存储端口和交换机之间的链接丧失。 在最初的 15 秒延迟之后，FC 驱动程序请求查看设备是否在光纤网上。 如果不在光纤网上，那么 I/O 由适配器清空。 尽管存储驱动器（磁盘、磁带和 FastT）驱动程序可能在 I/O 重试之间插入很小一段延迟的时间（2-5 秒），但是如果设备仍然不在光纤网上，那么后续的重试或新的 I/O 会立即失败。 如果 FC 驱动程序检测到设备在光纤网上，但是 SCSI 标识已经更改，那么 FC 设备驱动程序会将流量重定向至新的 SCSI 标识。 |
| 是 | fast_fail |
如果驱动程序接收到来自交换机的注册状态更改通知 (RSCN)，这表明在远程存储端口和交换机之间的链接丧失。 在最初的 15 秒延迟之后，FC 驱动程序请求查看设备是否在光纤网上。 如果不在光纤网上，那么 I/O 由适配器清空。 如果设备仍然不在光纤网上，那么之后的重试或新的 I/O 会立即失败。 存储器驱动程序（磁盘、磁带和 FastT）可能不会在重试之间产生延迟。 如果 FC 驱动程序检测到设备在光纤网上，但是 SCSI 标识已经更改，那么 FC 设备驱动程序会将流量重定向至新的 SCSI 标识。 |
禁用动态跟踪时， fc_err_recov 属性的 delayed_fail 和 fast_fail 设置之间存在明显差异。 然而在启用动态跟踪之后，fc_err_recov 属性的设置就不那么重要了。 这是因为在动态跟踪和快速失败恢复策略中有一些重叠。 因此，启用动态跟踪实质上就是启用了一些快速失败的逻辑。
在光纤网上不能再获得该设备时，对于启用动态跟踪的 fc_err_recov 设置而言，一般的错误恢复过程是一样的。 这一细微的区别在于：如果 fc_err_recov 设置为 delayed_fail，那么存储器驱动程序可以选择在 I/O 重试之间插入延迟时间。 这会根据延迟值和重试次数，将 I/O 故障时间增加额外的量，然后再使 I/O 永久失效。 但是，如果 I/O 流量较高，那么 delayed_fail 与 fast_fail 之间的差异可能更明显。
SAN 管理员可能想要试验这些设置来为他们的环境找出正确的设置组合。