group_by_prio与multibus本质区别在于路径分组逻辑：前者按优先级分组并仅启用最高组，后者将所有路径扁平化轮询调度；前者依赖alua通告优先级，后者无此要求。
group_by_prio 和 multibus 的本质区别在哪
两者根本不是同一维度的策略：group_by_prio 是按路径优先级（来自 ALUA 或自定义 path_priority）把路径聚合成多个优先级组，高优先级组在线时，低优先级组完全不参与 I/O；multibus 是把所有可用路径视作一个扁平集合，轮询或随机分发 I/O，不区分主备。
常见错误现象是：明明配置了 path_grouping_policy group_by_prio，但 dmsetup ls --tree 显示只有一组，或者 failover 不触发——往往是因为底层存储没报告有效优先级（比如未启用 ALUA，或 priority 插件返回全 0）。
-
group_by_prio要求存储支持优先级通告（如 SCSI-3 ALUA），且 multipathd 配置中启用了对应path_selector和path_priority插件（如alua或ontap） -
multibus对存储无特殊要求，适合非 ALUA 环境（如某些 iSCSI 目标或老旧 FC 阵列），但无法实现真正的故障隔离 - ALUA 模式下，
group_by_prio可让 standby 控制器路径自动降为低优先级组，failover 时无需手动切换；multibus下所有路径始终参与调度，控制器故障后需依赖路径检测超时才能剔除失效路径
怎么确认当前生效的是哪个策略
别只看 /etc/multipath.conf 里的配置，实际运行策略以 multipath -ll 输出为准。关键看两处：
- 每条路径末尾括号里是否标注
active/enabled——group_by_prio下只有最高优先级组的路径显示active，其余组路径显示enabled（但不参与 I/O） - 输出顶部的
policy字段：若为service-time 0或queue-length 0，说明是multibus；若为failover 0，大概率是group_by_prio（因为 failover 模式对应单活组） - 用
multipathd show maps查看内部状态，字段pgpolicy明确显示group_by_prio或multibus
ALUA 未就绪时强行配 group_by_prio 会怎样
路径优先级全为 0，multipathd 会退化为 failover 模式（即单路径 active，其余全部 disabled），看起来像“主备”，但切换依赖 path_checker 超时（默认 5 秒），远慢于 ALUA 的秒级感知。
- 检查 ALUA 状态：用
sg_rtpg -d /dev/sdX看是否返回asym_access_state字段；若报错或无输出，说明存储未开启 ALUA - 确认
path_priority插件已加载：在/etc/multipath.conf中必须有path_priority "alua"（或对应厂商插件），且priority值不能硬编码为固定数字 - 如果存储确实不支持 ALUA，别硬套
group_by_prio——直接用multibus+rr_min_io_rq 1更稳，至少能利用多路径带宽
multibus 下路径故障恢复延迟高怎么办
multibus 默认使用 service-time 调度器，它依赖历史响应时间做路径选择，但路径刚恢复时没有历史数据，容易继续发 I/O 到已故障路径，直到检测超时（check_int 默认 5 秒）。
- 改用
queue-length调度器：在/etc/multipath.conf的defaults或devices块中加path_selector "queue-length 0"，它只看路径队列深度，新路径一上线就能立即承接流量 - 调小检测间隔：设
check_int 1（单位秒），但注意太小会增加 SCSI 查询负载，尤其对低端存储可能引发误判 - 确保
path_checker类型匹配：FC 阵列用tur，iSCSI 推荐readsector0，别混用
ALUA 是 group_by_prio 发挥作用的前提，不是开关一开就自动生效；而 multibus 看似简单，路径恢复时机却高度依赖调度器和检测参数的配合——这两点最容易被忽略。
