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

iSCSI 这三个字母，对很多刚接触企业级存储或虚拟化运维的朋友来说，可能只是文档里一个带英文缩写的协议名词。但在我过去八年维护过三十多套生产环境的服务器集群的经历里，iSCSI 不是“可有可无的附加功能”，而是真正把本地磁盘、NAS、SAN 和虚拟机三者串起来的那根“数据动脉”。Ubuntu 20.04 Server 作为长期支持（LTS）版本，稳定性和内核兼容性极佳，但它默认不启用 iSCSI 相关服务——这意味着你不能靠apt install之后就直接挂载一块远程 LUN；它需要你理解底层连接机制、认证逻辑、路径冗余策略和故障恢复行为。这不是一个“点几下就完成”的图形化安装，而是一次对 Linux 存储栈的实操体检。

我见过太多人卡在第一步：iscsiadm -m discovery -t sendtargets -p 192.168.1.100执行后返回空结果，反复检查 IP 却忽略防火墙规则里缺了3260/tcp端口放行；也见过有人成功登录 target 后，lsblk却看不到新磁盘，最后发现是 udev 规则没触发，得手动udevadm trigger --subsystem-match=block；更常见的是，在 VMware 或 Proxmox 上配置多路径时，明明启用了multipath-tools，却因/etc/multipath.conf里wwid匹配规则写错，导致两条路径始终只走一条，完全浪费了高可用设计。这些都不是 bug，而是 iSCSI 协议本身的设计哲学决定的：它把控制面（login/discovery）和数据面（SCSI 命令传输）严格分离，把认证、重连、超时、路径选择全部交由客户端自主决策——这给了你极致的可控性，也意味着你必须亲手填满每一个逻辑缺口。

所以这篇内容不是“Ubuntu 20.04 安装 iSCSI 的 5 分钟教程”，而是带你从零开始，用真实生产环境的标准，把 iSCSI 客户端完整搭起来：包括服务初始化、安全认证配置、自动重连机制、设备持久化挂载、多路径容灾部署，以及最关键的——如何验证每一步是否真正生效。它适合正在搭建私有云存储后端的 DevOps 工程师、需要对接 NAS 存储的数据库管理员、或是准备用 iSCSI 启动无盘系统的系统集成商。如果你只是想临时挂个 ISO 镜像测试，那本文可能“过度设计”；但如果你的 PostgreSQL 数据库正跑在这块远程磁盘上，或者你的 KVM 虚拟机磁盘文件存放在 iSCSI target 上，那么下面每一个参数、每一行命令、每一个检查点，都直接关系到业务连续性。

2. 整体架构设计与方案选型逻辑：为什么不用 initiator-utils，而坚持用 open-iscsi？

很多人搜索“Ubuntu 20.04 iSCSI 安装”，第一反应是sudo apt install iscsi-initiator-utils。这个包名确实存在，但它早已是历史遗留符号。自 Ubuntu 18.04 起，官方仓库已将 iSCSI initiator 统一归入open-iscsi包，而iscsi-initiator-utils只是它的兼容性别名，实际安装的仍是同一套二进制。但真正值得深究的，是为什么我们不选其他方案？比如用tgt或lio自建 target（服务端），或者用iscsitarget？答案很现实：Ubuntu 20.04 Server 的定位是稳定可靠的客户端角色，而非存储服务提供者。它的核心任务是作为计算节点，可靠地接入外部专业存储设备（如 TrueNAS、Synology、Dell EMC Unity、NetApp FAS），而不是自己充当 target 去承担 I/O 压力和数据一致性风险。

open-iscsi 是 Linux 内核原生支持的用户态 initiator 实现，由 Linux-iSCSI 社区长期维护，深度集成于 systemd、udev 和 multipath 框架。它不像某些第三方工具那样绕过内核 SCSI 层，而是通过libiscsi库与内核scsi_transport_iscsi模块协同工作，确保所有 SCSI 命令（INQUIRY、READ CAPACITY、MODE SENSE、READ/WRITE）都能被正确封装、序列化并送达 target。更重要的是，它原生支持 CHAP（Challenge-Handshake Authentication Protocol）双向认证、动态发现（SendTargets）、自动重连（node.startup = automatic）、连接超时（node.conn[0].timeo.*系列参数）等企业级特性。而像iscsitarget这类老式项目，早在 2017 年就停止维护，其内核模块与 Ubuntu 20.04 的 5.4 内核存在兼容性问题，modprobe iscsitarget会直接报错Operation not permitted。

另一个常被忽略的关键点是 multipath 支持。现代企业存储几乎都提供双控制器或多路径访问能力（例如 TrueNAS 的 HA 集群、Dell SC 系列的 dual-active controller）。open-iscsi 与multipath-tools的配合是经过 Red Hat、SUSE、Canonical 多年联合测试的黄金组合。它能自动识别同一 LUN 的多个路径（不同 IP + 端口组合），并基于wwid（World Wide Identifier）生成唯一的设备别名（如/dev/mapper/36001405a1b2c3d4e5f67890123456789），彻底规避/dev/sdb在重启后变成/dev/sdc的设备名漂移问题。而如果强行用iscsiadm手动管理多路径，不仅配置复杂，且无法利用multipathd的实时路径健康检测和故障切换能力——当一条链路中断时，multipathd能在 200ms 内完成切换，而纯iscsiadm方案可能需要等待 TCP 重传超时（默认 30 秒），这对数据库事务是灾难性的。

因此，我们的方案非常明确：仅安装open-iscsi，禁用所有非必要服务，专注配置 initiator 客户端行为，与标准 Linux 存储栈（udev, multipath, fstab）无缝集成。不引入额外 daemon，不修改内核模块加载顺序，不覆盖系统默认 udev 规则——所有改动都限定在/etc/iscsi/和/etc/multipath.conf两个配置目录内，确保升级 Ubuntu 时配置零冲突。

2.1 服务初始化与 systemd 单元深度解析

Ubuntu 20.04 默认安装open-iscsi后，并不会自动启动iscsid服务。这是有意为之的设计：initiator 必须显式启动，避免在未配置 target 的情况下盲目尝试连接。iscsid是核心守护进程，负责管理所有 iSCSI 会话（session）、处理 CHAP 认证、响应 target 的 NOP 请求（keep-alive）、执行路径故障检测。它不是一个“后台常驻”服务，而是一个按需激活的 socket-activated daemon。

我们先确认当前状态：

systemctl status iscsid # 输出通常为 inactive (dead)，因为尚未配置任何 node

启动并设为开机自启：

sudo systemctl enable iscsid sudo systemctl start iscsid

但关键不在start，而在理解iscsid.socket的作用。查看其定义：

systemctl cat iscsid.socket

你会看到它监听/var/run/iscsi.sock这个 Unix domain socket。所有iscsiadm命令（如iscsiadm -m discovery）都通过这个 socket 与iscsid进程通信。这意味着：即使iscsid进程暂时退出，只要 socket 文件存在，下一次iscsiadm调用就会自动拉起它。这种设计极大提升了可靠性——你不需要担心iscsid崩溃导致整个 initiator 失效。

然而，iscsid本身不处理设备映射。设备发现、登录、LUN 映射由iscsiadm命令驱动，而设备节点创建（如/dev/sdb）则由 udev 完成。open-iscsi提供了专用的 udev 规则/lib/udev/rules.d/60-open-iscsi.rules，它监听内核scsi子系统事件，一旦检测到新 SCSI 设备（ACTION=="add"且SUBSYSTEM=="scsi"），就触发/sbin/open-iscsi脚本，该脚本会调用iscsiadm -m node -T <targetname> -p <ip:port> --op show查询该设备是否属于已知 node，若是，则设置正确的权限（OWNER="root",GROUP="disk"）并触发blkid扫描文件系统类型。这就是为什么你iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --login后，lsblk立刻能看到新磁盘——背后是 udev 规则链的精准触发。

提示：不要手动修改/lib/udev/rules.d/下的规则。如需定制（例如为特定 target 设置固定设备名），应在/etc/udev/rules.d/下创建99-iscsi-persistent.rules，使用SYMLINK+="iscsi-disk1"规则，并确保PROGRAM=="/bin/sh -c 'echo $ID_SERIAL_SHORT'"等条件匹配。直接改系统规则会导致apt upgrade时被覆盖。

2.2 安全认证模型：CHAP 双向认证为何不可省略？

iSCSI 协议本身不加密数据传输（TCP 层明文），因此认证是第一道防线。Ubuntu 20.04 的open-iscsi支持三种认证方式：None（不认证）、CHAP（单向）、Mutual CHAP（双向）。生产环境唯一可接受的是Mutual CHAP。原因很简单：单向 CHAP 只验证 initiator 身份，target 仍可能被伪造（例如攻击者搭建恶意 target 诱骗 client 登录，窃取 LUN 列表）；而 Mutual CHAP 要求 initiator 和 target 双方互相证明身份，形成双向信任链。

配置流程分三步：

1. 在 target 端（如 TrueNAS）创建 CHAP 用户（如iscsi_user）和密钥（如A1b2C3d4E5f6G7h8），并启用 Mutual CHAP；
2. 在 Ubuntu client 端，编辑/etc/iscsi/iscsid.conf，取消注释并修改以下行：

   node.session.auth.authmethod = CHAP node.session.auth.username = iscsi_user node.session.auth.password = A1b2C3d4E5f6G7h8 node.session.auth.username_in = iscsi_user node.session.auth.password_in = A1b2C3d4E5f6G7h8

   注意username_in和password_in是 target 向 initiator 发起认证时使用的凭据，必须与 target 端配置的“incoming”用户一致；
3. 对每个 node 单独启用认证：

   iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.authmethod -v CHAP iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.username -v iscsi_user iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.password -v A1b2C3d4E5f6G7h8 iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.username_in -v iscsi_user iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.password_in -v A1b2C3d4E5f6G7h8

这里有个极易踩的坑：iscsid.conf中的全局配置（node.session.auth.*）只对新创建的 node 生效。如果你已经用iscsiadm -m discovery发现了 target 并创建了 node，那么必须用--op update逐个更新现有 node 的参数。否则，iscsiadm -m node --login会因认证失败返回iscsiadm: Could not login to the iSCSI session，且日志/var/log/syslog中会显示CHAP authentication failed。

注意：iscsid.conf中的密码明文存储是安全风险。生产环境应使用iscsi-iname生成唯一 initiator 名（如iqn.1993-08.org.debian:01:abcd1234ef56），并在 target 端将该名与 CHAP 用户绑定，避免密码硬编码。但 Ubuntu 20.04 默认 initiator 名为iqn.1993-08.org.debian:01:$(hostname -s)，若 hostname 含特殊字符（如下划线），需手动修正/etc/iscsi/initiatorname.iscsi文件。

3. 核心实操步骤与关键参数详解：从发现到持久化挂载的全流程

现在进入实战环节。假设你的 target 地址是192.168.1.100，target name 是iqn.2005-10.org.freenas.ctl:storage，LUN ID 是0，目标是将其格式化为 ext4 并挂载到/mnt/iscsi-storage，且要求系统重启后自动连接、自动挂载、自动多路径。

3.1 发现 target 与创建 node：不只是iscsiadm -m discovery

发现 target 是整个流程的起点，但iscsiadm -m discovery -t sendtargets -p 192.168.1.100这条命令背后有诸多细节：

• -t sendtargets表示使用 SendTargets 方法，这是最通用的方式，target 会返回所有可用 portal（IP+端口）列表；
• -p 192.168.1.100指定 target IP，但不指定端口（默认 3260）。如果 target 监听非标端口（如 3261），必须写成-p 192.168.1.100:3261；
• 执行后，open-iscsi会在/var/lib/iscsi/nodes/下为每个发现的 target 创建子目录，目录名格式为<target_name>,<portal_ip>,<port>，例如iqn.2005-10.org.freenas.ctl:storage,192.168.1.100,3260；
• 该目录内包含default文件（存储 node 参数）和startup文件（记录启动模式）。

但仅仅发现还不够。你需要显式创建 node 并设置启动模式：

# 创建 node（如果 discovery 已自动创建，此步可跳过） sudo iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op new # 设置为自动启动（关键！否则 reboot 后不会自动 login） sudo iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.startup -v automatic # 启用 CHAP（如前文所述，此处省略具体 update 命令）

node.startup = automatic是核心开关。它告诉iscsid：当系统启动时，一旦网络就绪（network-online.target达成），就自动执行iscsiadm -m node -T <target> -p <ip> --login。但注意，它依赖iscsid.service的WantedBy=multi-user.target，且iscsid.socket必须处于 active 状态。你可以用systemctl list-dependencies iscsid.service查看其依赖树。

3.2 登录 session 与设备识别：为什么lsblk看不到新磁盘？

执行sudo iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --login后，理想情况是输出Logging in to [iface: default, target: iqn.2005-10.org.freenas.ctl:storage, portal: 192.168.1.100,3260]和Login to [iface: default, target: iqn.2005-10.org.freenas.ctl:storage, portal: 192.168.1.100,3260] successful.。此时，你应该立即检查：

1. Session 是否建立：

   iscsiadm -m session # 正确输出应类似：tcp: [1] 192.168.1.100:3260,-1 iqn.2005-10.org.freenas.ctl:storage (non-flash)

2. 内核是否识别 SCSI 设备：

   dmesg | tail -20 # 查找 "scsi" 关键字，应看到类似： # scsi host2: iSCSI Initiator over TCP/IP # scsi 2:0:0:0: Direct-Access FreeNAS iSCSI Disk 0001 PQ: 0 ANSI: 5 # sd 2:0:0:0: [sdb] 209715200 512-byte logical blocks: (107 GB/100 GiB)

   如果没有sdX行，说明 target 未正确暴露 LUN，或 initiator 未获得 LUN 权限（target 端 ACL 未添加 initiator IQN）。

3. udev 是否生成设备节点：

   ls -l /dev/sd* # 应看到新增的 /dev/sdb（或 sdc 等） # 同时检查 /dev/disk/by-path/ 下是否有 iscsi 相关链接 ls -l /dev/disk/by-path/ | grep iscsi # 输出类似：pci-0000:00:1f.2-ata-1.0 -> ../../sda # ip-192.168.1.100:3260-iscsi-iqn.2005-10.org.freenas.ctl:storage-lun-0 -> ../../sdb

如果lsblk仍无反应，90% 是 udev 规则未触发。强制刷新：

sudo udevadm trigger --subsystem-match=scsi sudo udevadm settle # 等待 udev 事件处理完毕

3.3 多路径配置：multipath-tools的正确打开方式

单路径虽能工作，但无法应对网络抖动或 target 控制器故障。TrueNAS 等 HA 存储通常提供两个 portal：192.168.1.100:3260和192.168.1.101:3260。我们需要让系统将它们识别为同一 LUN 的两条路径。

首先安装并启用 multipath：

sudo apt install multipath-tools sudo systemctl enable multipath-tools sudo systemctl start multipath-tools

关键在于/etc/multipath.conf配置。Ubuntu 20.04 默认配置文件为空白模板，需手动编写。一个最小可行配置如下：

defaults { user_friendly_names yes find_multipaths smart } blacklist { devnode "^vd[a-z]" devnode "^hd[a-z]" } devices { device { vendor "FreeNAS" product "iSCSI Disk" path_grouping_policy multibus getuid_callout "/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/%n" features "1 queue_if_no_path" hardware_handler "1 alua" prio "alua" failback immediate no_path_retry queue } }

逐项解释：

• user_friendly_names yes：启用mpathX别名（如/dev/mapper/mpatha），而非原始36001405...；
• find_multipaths smart：自动发现已知 WWID 的多路径设备，避免误判本地磁盘；
• blacklist：排除 virtio-blk (vdX) 和 IDE (hdX) 设备，防止 multipath 错误接管系统盘；
• vendor/product：精确匹配 target 厂商和型号，确保规则只应用于目标设备；
• path_grouping_policy multibus：所有路径视为同一组，负载均衡（round-robin）；
• getuid_callout：使用scsi_id获取 WWID，这是 multipath 识别同一 LUN 的唯一依据；
• features "1 queue_if_no_path"：当所有路径失效时，I/O 请求排队而非立即报错，给故障恢复留时间；
• hardware_handler "1 alua"：启用 ALUA（Asymmetric Logical Unit Assignment）支持，适配现代存储的优化路径；
• prio "alua"：优先级算法使用 ALUA，自动选择最优路径（如 Active/Active 模式下的首选控制器）；
• failback immediate：路径恢复后立即切回主路径；
• no_path_retry queue：无限期排队，直到至少一条路径恢复。

配置完成后，重载 multipath：

sudo systemctl restart multipath-tools sudo multipath -v2 # 详细模式扫描，查看是否识别到多路径

正常输出应包含：

create: mpatha (36001405a1b2c3d4e5f67890123456789) undef FreeNAS,iSCSI Disk size=100G features='1 queue_if_no_path' hwhandler='1 alua' wp=undef |-+- policy='round-robin 0' prio=50 status=active | |- 2:0:0:0 sdb 8:16 active ready running | `- 3:0:0:0 sdc 8:32 active ready running `-+- policy='round-robin 0' prio=10 status=enabled |- 2:0:0:1 sdd 8:48 active ready running `- 3:0:0:1 sde 8:64 active ready running

此时，/dev/mapper/mpatha就是你的稳定设备名，无论sdb/sdc如何变化，它始终指向同一 LUN。

3.4 持久化挂载：fstab 与 systemd mount unit 的双重保险

/dev/mapper/mpatha是稳定的，但直接写入/etc/fstab仍有风险：multipath 设备可能在 fstab 解析时尚未就绪。最佳实践是使用 systemd mount unit，实现依赖驱动的挂载。

首先，格式化设备（仅首次）：

sudo mkfs.ext4 -L ISCSI_STORAGE /dev/mapper/mpatha

然后创建 mount unit：

sudo tee /etc/systemd/system/mnt-iscsi-storage.mount << 'EOF' [Unit] Description=Mount iSCSI Storage Documentation=man:systemd.mount(5) Wants=multi-user.target After=multi-user.target Before=remote-fs.target [Mount] What=/dev/mapper/mpatha Where=/mnt/iscsi-storage Type=ext4 Options=defaults,noatime,nodiratime,errors=remount-ro [Install] WantedBy=multi-user.target EOF

关键点：

• Wants=和After=确保它在multi-user.target（即常规登录环境）之后启动；
• Before=remote-fs.target将其纳入远程文件系统依赖链；
• What=使用 mapper 设备，而非原始/dev/sdb；
• Options=中noatime和nodiratime减少元数据写入，提升性能；errors=remount-ro在文件系统错误时降级为只读，避免数据损坏。

启用并测试：

sudo systemctl daemon-reload sudo systemctl enable mnt-iscsi-storage.mount sudo systemctl start mnt-iscsi-storage.mount df -h /mnt/iscsi-storage

实操心得：不要在 fstab 中使用x-systemd.requires=multi-user.target这类 hack。systemd mount unit 是官方推荐方式，且能正确处理设备就绪依赖。我曾在一个客户环境里，因 fstab 中UUID=...指向/dev/sdb，而 reboot 后 udev 规则延迟导致sdb变成sdc，结果挂载失败，数据库服务无法启动。改用 mapper + mount unit 后，问题彻底消失。

4. 常见问题排查与避坑指南：来自 37 次现场排障的真实记录

在 Ubuntu 20.04 上部署 iSCSI，90% 的问题集中在连接建立、设备识别和路径稳定性三个环节。以下是我在真实环境中记录的高频问题及解决路径，附带命令和日志分析技巧。

4.1 连接类问题：iscsiadm返回No portals found或Connection refused

现象：iscsiadm -m discovery -t sendtargets -p 192.168.1.100无输出，或报错iscsiadm: can't connect to iSCSI daemon!。

排查链路：

1. 检查 iscsid 是否运行：

   sudo systemctl status iscsid # 若 inactive，执行 sudo systemctl start iscsid # 若 failed，查看 journal: sudo journalctl -u iscsid -n 50 --no-pager

2. 验证 target 端可达性：

   telnet 192.168.1.100 3260 # 或 nc -zv 192.168.1.100 3260 # 若 connection refused，说明 target 未监听或防火墙拦截

3. 检查 Ubuntu 防火墙：

   sudo ufw status verbose # 必须允许 3260/tcp 入站（client 不需要出站规则，因为连接是 outbound） sudo ufw allow 3260/tcp

4. 确认 target 端配置：

   • TrueNAS：Services → iSCSI → Portal → 确认 IP 绑定正确（非0.0.0.0）；
   • Synology：Control Panel → File Services → iSCSI LUN → Target → 确认 “Enable CHAP authentication” 已勾选，且 “Initiator IP Address” 添加了 client 的 IP 段。

根本原因：No portals found通常是 target 未响应 SendTargets 请求，而非 client 端问题。务必先排除网络层和 target 配置。

4.2 设备识别类问题：iscsiadm --login成功但lsblk无新设备

现象：Login successful，iscsiadm -m session显示 session，但lsblk和/dev/sd*无新增。

日志定位：

sudo dmesg | grep -i "scsi\|iscsi" # 关键线索：查找 "reject"、"timeout"、"reset" 字样 # 例如："scsi 2:0:0:0: rejecting I/O to offline device"

典型原因与修复：

• LUN 未映射或 ACL 未授权：target 端未将 LUN 分配给该 initiator IQN。在 TrueNAS 中，进入 Target Extent → Associated Targets，确认 initiator IQN 在列表中。
• udev 规则未触发：手动触发：

  sudo udevadm trigger --subsystem-match=scsi --action=add sudo udevadm settle

• 内核 SCSI 模块未加载：检查lsmod | grep scsi，确保scsi_mod、sd_mod、iscsi_tcp已加载。若缺失，sudo modprobe scsi_mod sd_mod iscsi_tcp。
• 设备忙或冲突：dmesg显示Device sdb is busy。可能是旧 session 未清理干净，执行sudo iscsiadm -m node -T <target> -p <ip> --logout后重试。

4.3 多路径类问题：multipath -ll显示undef或路径状态异常

现象：multipath -ll输出中status=undef，或active/enabled状态混乱。

诊断命令：

sudo multipath -v3 # 最详细扫描，显示每条路径的探测过程 sudo systemctl status multipath-tools sudo journalctl -u multipath-tools -n 50 --no-pager

常见陷阱：

• WWID 不一致：两条路径返回的scsi_id不同。原因可能是 target 端未启用 ALUA，或getuid_callout命令错误。验证：

  sudo /sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/sdb sudo /sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/sdc # 两者输出必须完全相同

• ALUA 未启用：在/etc/multipath.conf中，hardware_handler和prio必须匹配。若 target 不支持 ALUA，改用prio "const"和hardware_handler "0"。
• 路径 timeout 过短：默认rr_min_io_rq为 1，导致频繁切换。在devices{}块中添加：

  rr_min_io_rq 128 rr_weight priorities

4.4 挂载类问题：reboot 后/mnt/iscsi-storage为空或报错mount: special device /dev/mapper/mpatha does not exist

根源：systemd 启动顺序竞争。multipath-tools服务可能晚于 mount unit 启动。

解决方案：

1. 强制 mount unit 依赖 multipath：

   sudo systemctl edit mnt-iscsi-storage.mount

   输入：

   [Unit] Wants=multipath-tools.service After=multipath-tools.service

2. 添加设备就绪等待：

   sudo systemctl edit mnt-iscsi-storage.mount

   添加：

   [Mount] What=/dev/mapper/mpatha Where=/mnt/iscsi-storage # ... 其他选项 Options=defaults,noatime,nodiratime,errors=remount-ro,x-systemd.device-timeout=90

   x-systemd.device-timeout=90告诉 systemd 最多等待 90 秒，直到设备出现。

3. 验证依赖图：

   systemctl list-dependencies --reverse mnt-iscsi-storage.mount # 应看到 multipath-tools.service 在列表中

我的避坑笔记：在某次金融客户部署中，因未加x-systemd.device-timeout，系统启动时 mount unit 超时失败，后续服务（如 PostgreSQL）因数据目录不可用而崩溃。添加后，启动日志显示Waiting for device /dev/mapper/mpatha...，90 秒内成功挂载。这个参数是生产环境的必备项。

5. 性能调优与生产环境加固：让 iSCSI 真正扛住业务压力

完成基础连接后，真正的挑战才开始：如何让这块远程磁盘的 I/O 性能接近本地 SSD？如何确保在链路抖动时业务无感？这需要深入内核参数和 iSCSI 会话调优。

5.1 TCP 层调优：突破默认拥塞控制瓶颈

iSCSI 基于 TCP，而 Ubuntu 20.04 默认的cubic拥塞算法在高延迟（>50ms）或丢包率 >0.1% 的网络中表现不佳。我们改为bbr（Bottleneck Bandwidth and RTT）：

echo 'net.core.default_qdisc=fq' | sudo tee -a /etc/sysctl.conf echo 'net.ipv4.tcp_congestion_control=bbr' | sudo tee -a /etc/sysctl.conf sudo sysctl -p

验证：

sysctl net.ipv4.tcp_congestion_control # 应输出 bbr

bbr能更准确估计带宽和 RTT，避免cubic的激进窗口增长导致队列堆积。在跨机房（如北京-上海