iSCSI session 反复 logout/login 的根本原因是底层连接不稳定或上下配置未对齐，常见诱因包括 recovery_tmo 设置不当、session timeout 过短、MPIO 路径状态异常及 queue_depth 不匹配；生产环境建议 recovery_tmo 设为 60～120 秒，queue_depth 需与 target 端能力对齐，避免命令堆积触发超时。
为什么 iSCSI session 会反复 logout/login？
根本原因通常是底层连接不稳定或上层配置未对齐，导致 iscsid 主动终止 session 并重试。常见诱因包括：session timeout 过短、recovery_tmo 设置为负数或过小、MPIO 路径未正确标记为 active、queue_depth 在 initiator 和 target 侧不匹配引发命令堆积超时。
关键参数：timeout 和 recovery_tmo 怎么设才稳？
timeout（即 node.session.timeo.logout_timeout）仅控制 logout 命令本身的等待时间，一般保持默认 15 秒即可；真正影响 session 存活的是 recovery_tmo（node.session.timeo.recovery_tmo）。它决定 session 失联后容忍多久才彻底放弃并重建：
- 设为
-1：启用无限重试（不推荐，可能掩盖真实链路问题） - 设为
0：立即 abort，易触发频繁 login - 生产环境建议设为
60～120（秒），配合网络设备的 BPDUs/keepalive 间隔（如交换机 LACP 超时通常为 90s） - 修改后必须执行
iscsiadm -m node -u+-R重新登录才生效
MPIO 多路径下 session 行为异常怎么办？
iSCSI MPIO 不是自动负载均衡，而是依赖 path_selector 和路径状态。频繁 login/logout 往往因为部分路径被标记为 faulty 后未及时恢复，或所有路径都 fallback 到同一个 session：
- 确认每条路径是否独立 session：
iscsiadm -m session -P 3 | grep "Target|Iface"，应看到多个sessionID 对应不同iface - 检查路径状态：
multipath -ll中每个mpath的状态应为active且有多个healthy路径 - 避免使用
round-robinpath_selector 配合非对称存储（如某些 nas 只允许单路径写入），优先选service-time或queue-Length -
node.startup = manual必须设为auto，否则 multipathd 无法在路径恢复后自动 re-login
queue_depth 不匹配会导致什么？
queue_depth 是每个 SCSI 设备（即每个 /dev/sdX）能挂起的最大未完成命令数。initiator 默认值（如 linux 的 scsi_mod.use_blk_mq=1 下常为 128）若远高于 target 允许值（如某些 iSCSI target 最大只支持 32），会造成命令在 initiator 侧堆积，触发 recovery_tmo 超时进而 logout。
- 查 initiator 当前值：
cat /sys/block/DEVICE/device/queue_depth - 查 target 限制：需查阅对应 target 文档（如 LIO 默认 128，FreeNAS/iXsystems 默认 64）
- 调整方式（永久）：
echo 'options scsi_mod use_blk_mq=1' > /etc/modprobe.d/scsi.conf，再用udev规则或scsi_hostsysfs 接口设具体值 - 特别注意：NVMe over Fabrics 等新协议中
queue_depth概念已由nr_io_queues和queue_depth共同决定，不能直接套用
实际调优时，recovery_tmo 和 queue_depth 的组合影响最大——前者管“等多久”，后者管“等什么”。很多 case 表面是网络抖动，实则是 queue_depth 过大导致 recovery_tmo 被误触发。先锁死 target 端能力，再反推 initiator 配置，比盲目拉长超时更治本。