FC-SAN链路连通需三重验证：HBA卡port_state为Online且port_speed正常、remote_port port_state为Online、multipath -ll显示active路径；缺一不可。
光纤SAN链路是否连通，不能只看ip link或ifconfig——那些对FC设备完全无效。真正要确认的是HBA卡与远端存储端口之间物理光路、FC协议层、多路径识别三者是否全部就绪。
查HBA卡物理端口状态（hostX下link是否up）
FC链路最底层的“通不通”，得看HBA卡自身的端口状态。Linux把每个FC HBA抽象为/sys/class/fc_host/hostX，其中port_state和port_speed是关键：
-
cat /sys/class/fc_host/hostX/port_state：正常应为Online；若为Linkdown、Unknown或Offline，说明物理光路未建链（光模块未插、SFP故障、交换机端口shutdown、zone未包含该WWPN） -
cat /sys/class/fc_host/hostX/port_speed：显示协商速率（如8 Gbps），为unknown往往意味着底层link未建立 - 注意
hostX编号不固定，用ls /sys/class/fc_host/确认实际存在哪些host；多卡服务器常见host0、host1等
查远程FC端口是否可见（remote_portX是否online）
HBA卡上线后，会尝试发现远端设备。这些设备在内核中表现为/sys/class/fc_remote_port/rport-X:X:X/目录，核心判断依据是port_state：
-
ls /sys/class/fc_remote_port/列出所有已发现的远端端口 - 对每个
rport-*，执行cat port_state：必须为Online才表示该远端FC端口（比如存储阵列的某个控制器端口）已被成功识别 - 若
port_state为Not present或Unknown，常见原因包括：zone配置遗漏、存储端未开启该端口、LUN未映射到主机WWPN、FC交换机未启用名称服务（NS） - 可配合
cat node_name和cat port_name核对看到的是否为预期存储设备的WWNN/WWPN（例如华为OceanStor常见WWN前缀20029c37...）
查多路径设备是否生成（multipath -ll有无active路径）
即使HBA和remote_port都online，如果multipath没识别出LUN，说明SAN链路在逻辑层仍未贯通。这是最容易被忽略的“最后一公里”：
- 运行
multipath -ll：若有输出且状态含active、ready，并列出多个sda、sdb等路径，说明LUN已通过多路径聚合成功 - 若输出为空或提示
no paths to device，但前面两步都正常，则问题一定出在存储侧：LUN未映射给主机组、主机组未绑定服务器WWPN、或存储端未执行rescan刷新LUN视图 - 临时触发重发现可用
echo 1 > /sys/class/scsi_host/hostX/scan（X为对应host编号），但更稳妥的是用rescan-scsi-bus.sh -a -r -m全量扫描 - 注意：
lsblk或fdisk -l能看到sdX设备，不代表它已被纳入multipath管理——必须multipath -ll里出现才算SAN链路真正可用
为什么ethtool对FC接口无效？
ethtool只作用于以太网设备（eth0、ens33等），它读取的是PHY/MAC寄存器，而FC HBA走的是独立的Fibre Channel子系统，驱动模型、寄存器空间、诊断接口完全不同。对fc_host执行ethtool会直接报错No such device。别浪费时间试这个。
真正容易卡住的地方，往往不是“有没有光”，而是remote_port状态为Online但multipath看不到设备——这时候得立刻切回存储侧检查LUN映射和主机组绑定，而不是继续在Linux上翻日志。
