Ubuntu 20.04 iSCSI Initiator 精准部署指南：从发现到高可用挂载

1. 为什么在 Ubuntu 20.04 Server 上认真装一次 iSCSI，比你想象中重要得多

iSCSI——这三个字母在数据中心、虚拟化平台和中小型企业存储架构里，从来不是个“可有可无”的配角。它不是那种装完就忘的工具，而是你真正把服务器当“存储节点”用的第一道门槛。我见过太多人，在 Ubuntu 20.04 Server 上随手apt install open-iscsi就以为万事大吉，结果一上生产环境：挂载延迟飙升、多路径切换失灵、重启后设备丢失、甚至数据库写入卡顿十几秒——最后排查三天，发现根本不是网络问题，而是 iSCSI initiator 配置里一个node.session.timeo.replacement_timeout参数设成了 0，导致连接中断后直接放弃重连，而不是等待目标恢复。

Ubuntu 20.04 Server 是 LTS 版本，内核为 5.4，自带的open-iscsi包版本是 2.0.874-7ubuntu1（Debian/Ubuntu 官方源），这个版本对现代 SAN 设备兼容性良好，但默认配置极度保守：超时时间过长、重试策略僵硬、多路径支持未启用、CHAP 认证模板缺失——这些都不是 bug，而是设计哲学：宁可“连不上”，也不“连错”。所以，所谓“安装 iSCSI”，本质不是执行几条命令，而是完成一次存储协议栈的精准校准：从内核模块加载时机，到会话建立握手细节；从 SCSI 设备识别逻辑，到 udev 规则对/dev/sdX命名的持久化控制；从 systemd 服务依赖顺序，到 multipathd 启动时序——每一步都牵一发而动全身。

如果你正打算用这台 Ubuntu 20.04 Server 接入 NetApp、Dell EMC Unity、QNAP TS-x73 或 VMware vSphere 的 iSCSI Datastore；或者你要部署 PostgreSQL 主从集群，把 WAL 归档目录挂到远程块设备；又或者你在做 CI/CD 流水线，需要把构建产物直接写入高可用存储卷——那么你不是在装一个“网络硬盘”，而是在构建一条带状态、可审计、可故障转移的存储链路。它不像 NFS 那样靠文件语义兜底，iSCSI 是裸块协议，OS 看到的就是一块物理盘，任何配置偏差都会被放大成 I/O 错误、内核 panic 或应用层超时。所以这篇内容不讲“怎么快速跑起来”，而是带你走一遍真实运维场景下必须闭环的 7 个关键环节：initiator 初始化、target 发现与登录、设备持久化绑定、multipath 多路径收敛、CHAP 双向认证加固、udev 规则定制、以及 systemd 服务依赖编排。每一个环节，我都附上了实测参数、错误日志片段、调试命令和线上踩坑记录。

适合谁看？第一类：刚从桌面版 Ubuntu 转过来的系统管理员，对iscsiadm命令还停留在--mode discovery阶段；第二类：正在搭建 Proxmox VE 或 OpenStack 的工程师，需要确保虚拟机磁盘后端稳定可靠；第三类：DBA 或 DevOps 工程师，要把 MySQL 数据目录或 Kafka 日志目录挂到 iSCSI 卷，不能接受毫秒级 I/O 抖动。别担心术语多——我会用“快递柜收件”类比 target discovery，用“双车道收费站”解释 multipath failover，用“银行U盾认证”说明 CHAP 流程。所有命令都经过 Ubuntu 20.04 Server 环境实测，拒绝照搬 ArchWiki 或 Red Hat 文档的参数。

2. 整体架构设计与方案选型逻辑：为什么不用 Webmin 或 Cockpit 图形界面

很多人看到“Ubuntu Server 安装 iSCSI”，第一反应是搜“Ubuntu iSCSI GUI 教程”，然后装 Webmin 或 Cockpit 插件。我明确告诉你：在生产级 iSCSI 部署中，图形界面是最大的认知陷阱。这不是偏见，而是血泪教训。去年我们给一家医疗影像系统做存储扩容，运维同事图省事用 Cockpit 点了几下就完成了 initiator 配置，上线两周后 PACS 系统频繁报“DICOM 存储写入失败”。抓包发现，Cockpit 自动生成的/etc/iscsi/nodes/下配置文件里，node.startup = automatic被错误写成automatic（少了个空格），导致iscsid服务启动时跳过该节点加载；更致命的是，它把node.session.iscsi.InitialR2T强制设为No，而我们的 Dell SCv3000 target 要求必须为Yes才能协商成功——这个参数在 GUI 里根本不可见，只在 raw 配置文件里暴露。

所以，本方案坚持纯 CLI + 配置文件驱动，原因有三：
第一，可审计性。每一条iscsiadm命令都有完整日志（/var/log/syslog中以iscsi开头），每次修改/etc/iscsi/iscsid.conf都能用git diff追踪；而 GUI 操作像黑盒，你不知道它背后执行了哪些iscsiadm -m node -T ... -p ... --op=update。
第二，确定性。Ubuntu 20.04 的open-iscsi包对 systemd 集成做了深度适配，iscsid.service和open-iscsi.service的启动顺序、依赖关系、restart 策略都经过严格测试。GUI 工具往往绕过 systemd，直接调用iscsiadm，导致服务状态与 systemd 记录不一致，systemctl status open-iscsi显示 active，实际iscsiadm -m session查不到会话。
第三，故障定位效率。当你遇到iscsiadm: No portals found，CLI 下iscsiadm -m discoverydb -t sendtargets -p <ip>:3260 -I default --op=show一行命令就能确认 discoverydb 条目是否注册；而 GUI 里你得点开三层菜单找“发现门户列表”，再导出日志，再 grep。

具体技术栈选型如下：

• Initiator：Ubuntu 20.04 官方源open-iscsi（2.0.874-7ubuntu1），不升级到第三方 PPA 版本。理由：LTS 系统稳定性优先，新版本可能引入内核模块 ABI 不兼容（如 2.1.x 版本要求 kernel >= 5.8）。
• Target：不指定具体厂商，但所有配置均兼容主流 target 实现（Linux LIO、FreeNAS/iXsystems TrueNAS、NetApp ONTAP、VMware vSphere iSCSI Software Adapter）。重点适配SendTargetsdiscovery 方式（非SLP或iSNS），这是最通用、最可控的方式。
• Multipath：multipath-tools（0.7.9-3ubuntu4），与open-iscsi同源，避免混用 Debian backport 版本导致 device-mapper 冲突。
• CHAP 认证：采用双向 CHAP（node.session.auth.authmethod = CHAP+discovery.sendtargets.auth.authmethod = CHAP），而非单向，因为单向仅验证 initiator，无法防止恶意 target 伪装。

提示：不要试图用iscsi-sfnet或ietd等老式 target 软件在 Ubuntu 上自建 target——这不是本篇目标。本文聚焦于作为 initiator 连接企业级 target，所有配置均以“客户端视角”展开，不涉及 target 端部署。

3. 核心细节解析与实操要点：从发现到登录的七步闭环

iSCSI 连接不是“一键挂载”，而是一个分阶段、有状态、可中断的协议交互过程。很多教程把iscsiadm -m discovery和iscsiadm -m node -l合并成一步，导致新手根本不知道中间发生了什么。下面我拆解真实环境中必须手动干预的七个关键环节，每个环节都标注了“为什么必须做”和“不做会怎样”。

3.1 初始化 iscsid 服务并验证内核模块

执行sudo systemctl enable --now iscsid后，必须立刻验证iscsi_tcp和libiscsi内核模块是否正确加载：

lsmod | grep -E "(iscsi|libiscsi)" # 正常输出应包含： # iscsi_tcp 20480 1 # libiscsi 61440 1 iscsi_tcp # scsi_transport_iscsi 40960 1 libiscsi

如果iscsi_tcp缺失，说明iscsid服务虽启动，但内核模块未加载。此时iscsiadm -m discovery会报iscsiadm: can't connect to iSCSI daemon (111)。根本原因是 Ubuntu 20.04 的open-iscsi包将iscsi_tcp模块设为softdep，需显式触发：

sudo modprobe iscsi_tcp echo "iscsi_tcp" | sudo tee -a /etc/modules

注意：libiscsi是用户态库，iscsi_tcp是内核态传输模块，二者缺一不可。曾有客户在 ARM64 服务器上因iscsi_tcp模块未编译进内核（CONFIG_ISCSI_TCP=m 但未加载），导致整个 iSCSI 功能失效，排查耗时两天。

3.2 Discovery DB 注册：不是“扫IP”，而是“记门牌号”

iscsiadm -m discoverydb -t sendtargets -p 192.168.1.100:3260 -I default --op=new这条命令，本质是往/var/lib/iscsi/send_targets/下创建一个数据库条目，不是实时扫描。很多人误以为执行后就能看到 target 列表，其实这只是“登记备案”。必须紧接着执行：

sudo iscsiadm -m discoverydb -t sendtargets -p 192.168.1.100:3260 -I default --op=update sudo iscsiadm -m discoverydb -t sendtargets -p 192.168.1.100:3260 -I default --op=discover

其中--op=update更新 discoverydb 条目的刷新周期（默认 30 秒），--op=discover才真正发起 SendTargets 请求。若跳过update，discover可能使用过期缓存。实测发现，某些 NetApp target 在 discovery 后返回的 portal IP 是内网地址（如10.0.1.5），而 initiator 实际走的是192.168.1.100，这时必须手动编辑/var/lib/iscsi/send_targets/192.168.1.100,3260/st_config，把node.address改为10.0.1.5，否则登录失败。

3.3 Node 配置生成：自动 vs 手动的取舍

iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 -o new会生成/etc/iscsi/nodes/iqn.2001-05.com.example:storage.disk1.sys1.xyz/192.168.1.100,3260,1/目录。这里的关键是-o new参数：它只创建骨架，不写入任何认证参数。很多教程用-o update直接覆盖，但这样会丢失node.startup等关键字段。正确做法是：先new，再update逐项设置：

sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 -I default --op=update -n node.startup -v automatic sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 -I default --op=update -n node.session.auth.authmethod -v CHAP

实操心得：node.session.auth.authmethod必须设为CHAP，即使 target 不强制要求。因为None模式下，iscsid服务重启后可能因权限问题无法重建会话，而CHAP模式会触发 auth 重协商，成功率更高。

3.4 CHAP 认证参数注入：密码明文存储的安全妥协

Ubuntu 20.04 的open-iscsi不支持密钥环（keyring）集成，CHAP 密码必须明文写入/etc/iscsi/nodes/<iqn>/<ip,port,portal>/default文件。这是事实，不是缺陷。安全方案是：

1. 创建专用系统用户iscsi-auth，仅对该用户可读：

sudo adduser --disabled-password --gecos "" iscsi-auth sudo chown iscsi-auth:root /etc/iscsi/nodes/ sudo chmod 750 /etc/iscsi/nodes/

2. 用iscsiadm命令注入密码（避免手动编辑）：

sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 --op=update -n node.session.auth.username -v initiator01 sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 --op=update -n node.session.auth.password -v "MySecretPass123!"

iscsiadm会自动将密码写入default文件，并设置node.session.auth.password字段。手动编辑易出格式错误（如多空格、换行符）。

3.5 登录会话与设备识别：/dev/sdX命名的不确定性根源

执行sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 -l后，dmesg | tail -20会显示类似：

[ 1234.567890] scsi host2: iSCSI Initiator over TCP/IP [ 1234.568123] scsi 2:0:0:0: Direct-Access NETAPP LUN 1.0 PQ: 0 ANSI: 5 [ 1234.568456] sd 2:0:0:0: [sdc] 2097152000 512-byte logical blocks: (1.07 TB/1000 GiB)

注意[sdc]—— 这个sdc是内核按发现顺序分配的临时名，重启后可能变成sdd或sdb。这就是为什么不能直接mkfs.ext4 /dev/sdc。必须通过ls -l /dev/disk/by-path/找到持久化路径：

ls -l /dev/disk/by-path/ | grep "pci.*iscsi" # 输出类似： # lrwxrwxrwx 1 root root 9 Apr 10 10:20 pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sdc

这个pci-0000:00:1f.2-scsi-0:0:0:0是基于 PCI 总线地址和 SCSI 地址的唯一标识，不受sdx顺序影响。后续所有操作（fdisk,mkfs,fstab）都必须引用此路径，而非/dev/sdc。

3.6 Multipath 多路径初始化：不是“装软件”，而是“重定义设备树”

sudo apt install multipath-tools后，multipathd服务默认不启动。必须手动：

sudo systemctl enable --now multipathd

但此时multipath -ll仍为空，因为 multipath 服务默认只管理device-mapper设备，而 iSCSI 设备需显式声明。编辑/etc/multipath.conf：

defaults { user_friendly_names yes find_multipaths yes } devices { device { vendor "NETAPP" product "LUN" path_grouping_policy multibus path_selector "round-robin 0" features "1 queue_if_no_path" hardware_handler "1 alua" prio "alua" failback immediate } }

关键点：find_multipaths yes启用自动发现（需scsi_id工具），hardware_handler "1 alua"指定 ALUA（Asymmetric Logical Unit Assignment）处理，这是现代 SAN 的标准路径控制协议。执行sudo multipath -r重载配置，再multipath -ll应显示：

mpatha (3600a09803830365a0000000000000001) dm-2 NETAPP,LUN size=1.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw |-+- policy='round-robin 0' prio=50 status=active | |- 2:0:0:0 sdc 8:32 active ready running | `- 3:0:0:0 sdd 8:48 active ready running `-+- policy='round-robin 0' prio=10 status=enabled |- 2:0:0:1 sde 8:64 active ready running `- 3:0:0:1 sdf 8:80 active ready running

这里mpatha是 multipath 生成的统一设备名，sdc/sdd/sde/sdf是底层路径。所有 I/O 都经由mpatha，路径故障时自动切换。

3.7 fstab 挂载与 systemd 依赖：让存储随系统启动就绪

/etc/fstab中不能写/dev/sdc，也不能写/dev/mapper/mpatha（因为 mapper 名称在multipathd启动前不存在）。正确写法是：

/dev/disk/by-id/dm-name-mpatha /mnt/iscsi ext4 _netdev,x-systemd.requires=multipathd.service,x-systemd.after=multipathd.service 0 0

解释：

• _netdev告诉 mount 等待网络就绪；
• x-systemd.requires和x-systemd.after强制systemd在multipathd.service启动后再挂载；
• /dev/disk/by-id/dm-name-mpatha是 multipath 生成的持久化符号链接，指向/dev/mapper/mpatha。

验证：sudo systemctl daemon-reload && sudo reboot，重启后mount | grep iscsi应显示已挂载，且multipath -ll中所有路径状态为active ready。

4. 实操过程与核心环节实现：一份可直接复制粘贴的部署清单

以下是一份在 Ubuntu 20.04 Server（minimal install）上，从零开始部署 iSCSI initiator 的完整实操清单。所有命令均按真实执行顺序排列，包含参数说明、预期输出和错误处理。请逐行执行，不要跳步。

4.1 环境准备与基础依赖

# 更新系统并安装必要工具 sudo apt update && sudo apt full-upgrade -y sudo apt install -y open-iscsi multipath-tools lsscsi sg3-utils # 加载 iSCSI 内核模块并设开机加载 sudo modprobe iscsi_tcp echo "iscsi_tcp" | sudo tee -a /etc/modules # 启用并启动 iscsid 服务 sudo systemctl enable iscsid sudo systemctl start iscsid sudo systemctl status iscsid # 确认 active (running)

预期输出：Active: active (running)，且journalctl -u iscsid | tail -5无failed关键字。若报Failed to start iSCSI daemon，检查/var/log/syslog中iscsid相关错误，常见原因是/etc/iscsi/iscsid.conf语法错误（如多出空格）。

4.2 Target 发现与 Node 注册

假设 target IP 为192.168.1.100，IQN 为iqn.2001-05.com.example:storage.disk1.sys1.xyz：

# 注册 discovery db sudo iscsiadm -m discoverydb -t sendtargets -p 192.168.1.100:3260 -I default --op=new sudo iscsiadm -m discoverydb -t sendtargets -p 192.168.1.100:3260 -I default --op=update sudo iscsiadm -m discoverydb -t sendtargets -p 192.168.1.100:3260 -I default --op=discover # 查看发现结果 sudo iscsiadm -m discoverydb -t sendtargets -p 192.168.1.100:3260 -I default --op=show # 输出应包含： # discovery.address = 192.168.1.100 # discovery.port = 3260 # discovery.type = sendtargets # 创建 node 条目 sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 -o new

注意：-o new后不要立即-l，先配置认证参数。

4.3 CHAP 认证配置与登录

# 设置启动模式 sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 --op=update -n node.startup -v automatic # 启用 CHAP 认证 sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 --op=update -n node.session.auth.authmethod -v CHAP # 注入 initiator 用户名和密码（替换为你的实际值） sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 --op=update -n node.session.auth.username -v "initiator01" sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 --op=update -n node.session.auth.password -v "MySecretPass123!" # 登录会话 sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 -l

验证：sudo iscsiadm -m session应输出类似tcp: [1] 192.168.1.100:3260,1 iqn.2001-05.com.example:storage.disk1.sys1.xyz (non-flash)。若报login failed，检查 target 端 CHAP 用户是否启用、密码是否匹配、防火墙是否放行 3260 端口。

4.4 Multipath 配置与设备映射

# 启用 multipathd sudo systemctl enable multipathd sudo systemctl start multipathd # 编辑 multipath.conf（备份原文件） sudo cp /etc/multipath.conf /etc/multipath.conf.bak sudo tee /etc/multipath.conf << 'EOF' defaults { user_friendly_names yes find_multipaths yes } devices { device { vendor "NETAPP" product "LUN" path_grouping_policy multibus path_selector "round-robin 0" features "1 queue_if_no_path" hardware_handler "1 alua" prio "alua" failback immediate } } EOF # 重载配置 sudo multipath -r sudo multipath -ll # 应显示 mpatha 及其路径

提示：vendor和product值需根据sudo lsscsi -i输出调整。例如 QNAP target 显示QNAP,TS-873，则 vendor 设为QNAP，product 设为TS-873。

4.5 文件系统创建与持久化挂载

# 获取 multipath 设备 ID sudo scsi_id -g -u -d /dev/mapper/mpatha # 输出类似：3600a09803830365a0000000000000001 # 创建 ext4 文件系统（-E stride=32,stripe-width=64 优化大块 I/O） sudo mkfs.ext4 -E stride=32,stripe-width=64 /dev/mapper/mpatha # 创建挂载点 sudo mkdir -p /mnt/iscsi # 获取持久化设备路径 ls -l /dev/disk/by-id/ | grep mpatha # 找到类似：dm-name-mpatha -> ../../dm-2 # 编辑 fstab echo "/dev/disk/by-id/dm-name-mpatha /mnt/iscsi ext4 _netdev,x-systemd.requires=multipathd.service,x-systemd.after=multipathd.service 0 0" | sudo tee -a /etc/fstab # 测试挂载 sudo mount -a mount | grep iscsi # 应显示 /dev/mapper/mpatha on /mnt/iscsi type ext4

验证：sudo touch /mnt/iscsi/testfile && sudo rm /mnt/iscsi/testfile，确认读写正常。

4.6 服务依赖编排与重启验证

# 确保服务启动顺序正确 sudo systemctl daemon-reload sudo systemctl list-dependencies --after open-iscsi.service multipathd.service # 输出应显示 multipathd.service 在 open-iscsi.service 之后 # 重启验证 sudo reboot # 登录后执行： sudo iscsiadm -m session # 应有活跃会话 sudo multipath -ll # 应显示 active paths df -h | grep iscsi # 应显示挂载容量

实操心得：重启后若multipath -ll显示undef状态，执行sudo multipath -F && sudo multipath强制刷新。这是因为multipathd启动时iscsid会话尚未完全建立，需手动触发重发现。

5. 常见问题与排查技巧实录：那些文档里不会写的现场真相

iSCSI 部署中最耗时的不是配置，而是故障排查。下面整理我在真实客户现场遇到的 8 类高频问题，每类都给出现象、根因、诊断命令、解决步骤，并标注“新手最容易犯的错”。

5.1 现象：iscsiadm -m discovery返回空，但 telnet 3260 端口通

根因：target 未启用 SendTargets discovery，或 firewall 阻断了 iSCSI discovery response（UDP 3260 或 TCP 3260 的特定响应包）。
诊断：

# 抓包确认 discovery 请求是否发出及响应 sudo tcpdump -i any port 3260 -w discovery.pcap sudo iscsiadm -m discoverydb -t sendtargets -p 192.168.1.100:3260 -I default --op=discover # 停止抓包，用 Wireshark 分析 discovery.pcap，查找 "SendTargets" request 和 response

解决：

• 检查 target 管理界面，确认 “Enable SendTargets” 已勾选；
• 在 Ubuntu 上临时关闭 ufw：sudo ufw disable，测试是否恢复；
• 若必须开启防火墙，添加规则：sudo ufw allow from 192.168.1.0/24 to any port 3260 proto tcp。

5.2 现象：iscsiadm -m node -l成功，但lsblk不显示新设备

根因：target 返回的 LUN ID 为 0，但 initiator 默认只扫描 LUN 0，而某些 target（如旧版 FreeNAS）需显式设置node.session.scan = manual。
诊断：

# 查看内核日志中的 SCSI 设备发现 dmesg | grep -i "scsi.*add" # 若无输出，说明 SCSI 层未收到 LUN 报告

解决：

# 修改 node 配置，强制扫描 sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 --op=update -n node.session.scan -v manual # 重新登录 sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 -u sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 -l

5.3 现象：multipath -ll显示ghost或undef，路径状态异常

根因：multipathd服务启动时，iSCSI 会话尚未建立完成，导致设备未被识别。
诊断：

sudo systemctl status multipathd # 查看 journalctl -u multipathd | grep -i "failed\|ghost"

解决：

# 添加 systemd 依赖，确保 multipathd 在 iscsid 完全就绪后启动 sudo tee /etc/systemd/system/multipathd.service.d/override.conf << 'EOF' [Unit] After=iscsid.service Wants=iscsid.service EOF sudo systemctl daemon-reload sudo systemctl restart multipathd

5.4 现象：挂载后 I/O 极慢，iostat -x 1显示%util100%，await> 1000ms

根因：node.session.timeo.replacement_timeout默认为 30 秒，网络抖动时会持续重试，阻塞 I/O 队列。
诊断：

# 查看当前 timeout 设置 sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 --op=show | grep replacement # 输出：node.session.timeo.replacement_timeout = 30

解决：

# 降低超时，加速故障转移 sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 --op=update -n node.session.timeo.replacement_timeout -v 5 # 重启会话 sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 -u sudo iscsiadm -m node -T iqn.2001-05.com.example:storage.disk1.sys1.xyz -p 192.168.1.100:3260 -l

5.5 现象：重启后/mnt/iscsi未自动挂载，systemctl status显示Dependency failed

根因：fstab中_netdev选项生效，但network-online.target未就绪，而multipathd依赖网络。
诊断：

sudo systemctl list-dependencies --reverse network-online.target | grep