磁盘突然脱机但ping通，先检查iSCSI会话是否存活：运行iscsiadm -m session -P 3确认State为LOGGED IN且recovery_tmo为0；同时用watch -n1 'ss -tni src :3260 | grep ESTAB'观察TCP重传数，若＞5次/秒则链路不稳；若无会话输出，需重新discovery+login；抖动根因在物理层（SFP、线缆、交换机误码），非Linux配置问题。
磁盘突然脱机但网络ping通，先看iSCSI会话是否存活
ping通不代表iSCSI链路正常——它只说明三层IP可达，而iSCSI依赖TCP 3260端口稳定、无重传、无RST。一旦链路抖动，iscsiadm -m session可能显示会话仍在，但内核已无法下发IO，表现为lsblk里设备消失、dmesg刷出connection reset by peer或session recovery failed。
- 立刻执行
iscsiadm -m session -P 3，重点看State:是否为LOGGED IN，以及recovery_tmo是否非0（非0说明正在尝试恢复，但卡住了） - 同时运行
watch -n1 'ss -tni src :3260 | grep ESTAB'，观察TCP重传数（retrans字段）是否持续增长；>5次/秒基本可判定链路不稳 - 如果
iscsiadm -m session无输出，说明会话已被内核强制终止，不是“断开”，而是“已死”，此时必须重新discovery+login
抖动不是Linux报错，要从物理层查起
iSCSI本身不报“抖动”，它只暴露结果：IO超时、设备消失、disk busy飙升。根因在光纤或以太网物理层——比如SFP模块老化、线缆弯折过度、交换机端口误码率突增。操作系统看到的只是表象。
- 在存储侧（如华为OceanStor、TrueNAS）查对应端口的
线路误码统计，重点关注CRCErrors、LossOfSignal、SyncLoss是否在1小时内明显上升 - 在FC/FCoE交换机上跑
porterrshow（博科）或show interface counters（Cisco MDS），比对enc_in和enc_out是否同步增长（抖动典型特征） - 如果是纯以太网iSCSI，用
ethtool -S ethX检查rx_crc_errors、rx_frame_errors，>100次/分钟就值得怀疑物理链路
/etc/fstab写/dev/sdb1导致重启后挂载失败
这不是抖动问题，但抖动后最容易暴露这个坑：iSCSI设备名（sda/sdb）每次登录可能变化，靠名字写/etc/fstab会导致开机时mount失败、服务启动卡住，看起来像“磁盘又掉了”。
- 必须改用
UUID或WWID：用ls -l /dev/disk/by-id/找带scsi-前缀的持久路径，例如scsi-36001405a8b9e1c7d8e9f0a1b2c3d4e5f - 更新
/etc/fstab时，挂载项写成：/dev/disk/by-id/scsi-36001405... /mnt/data xfs _netdev,defaults 0 0，其中_netdev告诉systemd等网络就绪再挂载 - 别漏掉
node.startup = automatic：运行iscsiadm -m node -o update -n node.startup -v automatic对每个target单独设置，否则即使fstab正确，设备也不会自动登录
抖动恢复后设备没回来？别急着reboot
抖动过去后，设备常处于“内核已识别但未激活”状态，lsblk看不到，fdisk -l也空——这不是硬件故障，是SCSI中间层没刷新LUN列表。
- 先确认会话已重建：
iscsiadm -m session有输出且State为LOGGED IN - 强制触发内核重扫：
iscsiadm -m session --rescan（注意不是--login） - 再查设备：
ls /sys/class/scsi_device/应出现新目录；ls /dev/sd*应看到设备节点；最后partprobe通知内核分区表变更 - 如果仍无设备，可能是存储端LUN未重新映射，需登录存储管理界面确认该IQN对应的LUN是否仍在线并授权
链路抖动的修复不在Linux配置里，而在光模块、线缆、交换机端口这些摸得着的地方；而Linux上最常被忽略的，是把iSCSI当普通磁盘用——设备名、fstab硬编码、缺_netdev，这些都会让一次几秒的抖动演变成半小时的服务中断。
