最近，公司为一个跨境电商独立站准备扩容存储空间。原来我们租用的是一个香港云主机，系统盘 50 GB + 数据盘 200 GB，运行 MySQL + 上传图片 + 日志。因业务增长，预计图片／日志量在两个月内增长 3 倍 — 我们向云服务商申请新增一个 1 TB 的数据盘，用于存储用户上传内容 + 日志 +备份。对方报盘后，我们在控制面板看到“已挂载到实例”状态。

为避免重启服务（生产环境 24/7，高并发读写，不允许 downtime），我决定在系统内在线识别新盘、分区、挂载并投入使用。没想到 —— 加盘之后，运行 lsblk / fdisk -l 都没看到新的 /dev/sdX 或 /dev/vdX。

以下就是我从“怀疑是不是服务商的问题”到“确认是系统没识别 + 驱动/扫描机制的问题”，并最终解决的全过程。

排查思路与常见原因 — “为什么新增云硬盘 Linux 识别不到？”

在我自己的故障排查流程中，总结出以下几个常见原因 + 验证方式。其实很多都在一些技术文档／社区经验里有所提及。

我的实际排查 & 解决过程（真实命令 + 输出 + 心得）

注：我的系统是 Ubuntu 22.04 （也适用于大多数现代 Linux 发行版），云盘是通过服务商 Web 控制面板添加的，类型是“标准块存储（block volume）”，虚拟接口为 SCSI。

确认服务商面板显示“已挂载 / attached”

登录到 cloud provider 面板，确认新加的 1 TB 硬盘确实属于该实例，并已 attach。

虽然 UI 显示已挂载，但我仍记下 LUN ID，准备从 guest OS 端进一步确认。

检查内核日志，看 kernel 有没有 detect 到设备插入

dmesg | tail -n 50 | grep -i sd
dmesg | tail -n 50 | grep -i scsi
dmesg | tail -n 50 | grep -i nvme

结果：没有新条目。说明 kernel 没有捕捉到新设备上线。根据文档，如果 kernel 没 detect，好可能是虚拟化 / bridging 的问题，也可能是驱动没加载。

检查 SCSI / NVMe 驱动是否加载

lsmod | grep -E 'nvme|scsi_mod|sd_mod'

如果你看到 nvme 或 scsi_mod 模块没加载，就手动加载试试：

sudo modprobe scsi_mod
sudo modprobe sd_mod
sudo modprobe nvme   # 视服务商块设备类型而定

然后再看 dmesg 是否有新日志。我当时没问题 —— 驱动是加载的。

手动让 kernel 扫描 SCSI host，总线 rescan
Linux 默认添加盘时不一定自动扫描，需要手动触发。方法：遍历 /sys/class/scsi_host/ 下的 hostX，执行 scan。

for host in /sys/class/scsi_host/host*; do
  echo "- - -" | sudo tee "$host/scan"
done

之后，再运行 lsblk 或 fdisk -l。

我的情况：scan 后，不仅没有 /dev/sdb 出现，也没有新的 scsi 相关 dmesg 日志 → 排除了仅仅是扫描没及时触发的问题。

怀疑是服务商层面的挂载 / hypervisor 问题

我联系了服务商 support，要求他们在 hypervisor 层确认这个 1TB 卷是否 attach 到正确 VM，并且桥接（bridge / device‑map）是否正确。

服务商反馈“确实 attach”，“hypervisor 端看不到错误”。也就是说，从他们那端来看，一切正常 —— 更可能是 guest OS 看不到的原因。

尝试重启 VM（线下窗口 + 业务提醒）

虽然不想重启，但短时间停机窗口允许，我决定重启一次 VM。

重启后，一登陆，就能在 lsblk 下看到 /dev/sdb 1.0T。这说明 hypervisor → guest 之间桥接确实起作用，但 hot‑attach（运行中 attach）没有对 guest 生效。

分区 / 挂载盘

看到新设备后，进行标准分区 / 格式化 / 挂载流程：

# 使用 parted 创建 GPT 分区表并分区
sudo parted /dev/sdb --script mklabel gpt
sudo parted /dev/sdb --script mkpart primary ext4 0% 100%

# 格式化
sudo mkfs.ext4 /dev/sdb1

# 创建挂载点 & 挂载
sudo mkdir -p /data/uploads
sudo mount /dev/sdb1 /data/uploads

# 查看
df -h /data/uploads

然后修改 /etc/fstab，建议使用 UUID 而不是设备名，以防设备名变更。用 blkid 获取 UUID：

sudo blkid /dev/sdb1
# 假设输出: UUID="abcd-1234-ef56-..."
echo 'UUID=abcd-1234-ef56-...  /data/uploads  ext4  defaults,nofail  0  2' | sudo tee -a /etc/fstab

nofail 参数可防止挂载失败影响系统启动。

为什么会这样 — 背后的本质 & 教训

通过这次经历，我深刻认识到：“云服务器加盘 + 虚拟化 + Linux guest” 的环境中，很多地方看似“已经挂载 / attach”，但实际上 guest OS 层可能根本没感知 —— 特别是当系统不重启时。

具体几点教训：

• Linux 不会默认自动扫描新的 SCSI／SCSI‑bridge 磁盘。手动 echo "- - -" rescan 是必须步骤。
• 即便 rescan 后没识别，也可能是虚拟化平台桥接的问题，这部分普通用户（guest OS）看不到日志，需要和服务商／hypervisor 管理员配合。
• 对于大容量磁盘（如 1 TB、2 TB 以上），推荐使用 GPT 分区表 + parted/gdisk，不要用老旧 fdisk（可能局限于 MBR 或兼容性差）。
• 挂载时 /etc/fstab 最好使用 UUID + nofail，防止设备名变化或盘暂时不可用导致启动失败。

我在现场遇到的坑 & 细节 — 那些容易掉进的“地雷”

下面是真实发生的几个坑／细节 —— 如果你没经历过，很容易忽略，引发宕机／数据丢失／挂载失败等问题。

服务商 UI 与后台状态不同步

UI 显示 “attached / 已挂载”，但实际上后台 attach 操作失败（hypervisor logs show error 但没反馈给用户） —— 导致 guest 看不到硬盘。这个坑很难从 guest 端发现。

热插入（hot‑attach）与 guest OS 不兼容

尤其是某些老旧 Linux 内核 + 某些虚拟化桥接方式，热插入可能不能触发 SCSI 总线重新扫描，必须通过重启 VM。

分区工具默认 MBR，1 TB 以上用 MBR 可能有兼容性、容量限制

如果执意用 fdisk，可能会遇分区失败或未来扩容问题。

fstab 配置不慎

我曾一开始直接写 /dev/sdb1 /data/uploads ext4 defaults 0 0，后来一次重启发现系统挂载失败，导致某些服务因挂载失败出错。后来改成 UUID + nofail 才稳定。

总结 —— 给香港云服务器运营／运维者的建议

不要只相信控制面板 UI，要从 guest OS 层确认实际 attach / detect。

添加大盘后，尽量安排维护窗口，重启 VM：热插入不一定可靠。

分区用 GPT + parted／gdisk；挂载用 UUID + nofail。

写一个通用的 rescan 脚本，方便以后快速热插入／排查。

下面是我平时常用的 rescan 脚本，放到 /usr/local/bin/rescan_new_disks.sh：

#!/usr/bin/env bash
for host in /sys/class/scsi_host/host*; do
    echo "- - -" | sudo tee "$host/scan" >/dev/null
done
sleep 2
lsblk

用这个脚本，加盘后运行一下，一步到位。

最后，作为一家专注香港服务器租用／托管、运营跨境电商／直播／高并发业务的团队，我们更要重视这些基础但容易被忽视的细节 — 因为一次挂盘操作，如果失败，不光是硬盘看不到那么简单，可能导致整个服务异常、数据不一致、甚至用户体验崩塌。希望这次“我亲历 + 解决”的案例，对你未来写技术文章／运维实操有帮助。