根本原因是alua状态未被正确识别或multipathd未读取到，导致路径全标为failed/ghost而fallback至multibus；需确认ontap端lun启用alua、配置中启用hardware_handler "1 alua"和path_checker tur，并用multipath -v3 -d验证alua state。
path_grouping_policy 设为 failover 时，为什么故障切换不生效
根本原因不是策略本身错，而是存储端 ALUA 状态没被正确识别或 multipathd 没读到。比如 NetApp ONTAP 启用了 ALUA，但 path_grouping_policy failover 要求所有路径必须明确区分 “Active/Optimized” 和 “Standby”，如果 path_checker tur 返回超时或拒绝（常见于某些 LUN 未启用 ALUA），multipathd 就会把所有路径都标为 failed 或 ghost，导致 fallback 到默认的 multibus 行为，看起来像“切换失效”。
实操建议：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 先用
multipath -v3 -d查看 debug 输出里每条路径的ALUA state是否识别为active/optimized、active/non-optimized或standby - 确认
/etc/multipath.conf中对应 vendor section 启用了 ALUA 支持：hardware_handler "1 alua"和path_checker tur（不能用readsector0） - 对 NetApp 存储，必须确保 ONTAP 端 LUN 已启用 ALUA：
lun show -vserver <vs> -fields alua</vs>返回enabled - 避免在
defaults块中全局设path_grouping_policy failover，应只在devices块中针对具体厂商（如vendor "NETAPP"）设置
multibus 和 group_by_prio 混用时 I/O 卡顿的真相
multibus 看似“全路径都可用”，但实际会把所有路径归入同一 priority group；而 group_by_prio 依赖 prio 插件返回的数值做分组——如果插件没配或返回全 0，所有路径仍挤在一个组里，I/O 还是轮询发到所有路径，包括那些非优化路径。结果就是：本该走 Active/Optimized 的请求，被发到了 Standby 路径上，ONTAP 强制重定向，引入额外延迟甚至超时。
实操建议：
- NetApp 环境下优先用
path_grouping_policy group_by_prio+prio alua，而非multibus - 确认
prio alua插件已加载：ls /usr/libexec/multipath/prio_alua存在且可执行 - 检查
multipath -ll输出中各路径的prio值是否分层（如 Active/Optimized 显示 50，Active/Non-Optimized 显示 10，Standby 显示 0） - 若
prio全为 0，说明alua插件未生效，回退检查hardware_handler "1 alua"和存储端 ALUA 配置
failback immediate 导致路径震荡的典型场景
当设了 failback immediate，只要某条原故障路径恢复（哪怕只是短暂闪断后重连），multipathd 就立刻把它加回 active 组并重新分配 I/O。但如果该路径物理不稳定（例如光纤模块老化、交换机端口 CRC 错误高），就会反复“上线→收 I/O→出错→下线→再上线”，造成 I/O 延迟毛刺甚至应用报 Input/output error。
实操建议：
- 生产环境一律禁用
failback immediate，改用failback manual或failback 60（单位秒） - 配合
rr_min_io_rq 1（而非默认的rr_min_io 1000）降低单次轮询粒度，让负载更平滑 - 用
watch -n1 'multipath -ll | grep -E "(status|prio)"'实时观察路径状态变化节奏，确认无高频抖动 - 对关键业务路径，可在
devices块中单独设no_path_retry queue防止路径全断时直接报错
为什么 reload multipathd.service 后配置没生效
systemctl reload multipathd.service 只重载配置文件，但不会刷新已存在的多路径设备树。旧设备仍按启动时的策略运行，新策略只对后续发现的路径生效——这在存储扩容或路径增删后特别容易踩坑。
实操建议：
- 修改
/etc/multipath.conf后，必须执行：multipath -F && multipath -v2清空并重建设备树 - 确认
multipath -ll输出中设备名（如mpatha）后的括号里显示的是最新策略，例如[active][ready]而非[undef][ready] - 若设备已被 LVM 或文件系统使用，
multipath -F会失败，需先dmsetup remove_all（谨慎！确保无活跃 I/O） - 不要依赖
systemctl restart multipathd，它会中断正在运行的路径监控线程，可能引发瞬时 I/O hang
multipathd 解析 ALUA 状态 + prio 插件输出 + 内核 dm-mpath 驱动三者协同的结果。任何一个环节断开，策略就只剩空壳。
