LocalSync2026-02-20

群晖 DS918+ 10TB 硬盘扩容实战复盘

设备：Synology DS918+（DSM 7.x）+ DX517 扩展柜
阵列：SHR-1（底层 RAID5），原有 3×10TB（sda/sdb/sdd），新增第 4 块 10TB
时间线：2026 年 2 月 18 日 ~ 2 月 20 日

---

一、起因

我需要将大量 Elasticsearch 数据导出到 NAS 上的 ClickHouse，但 NAS 存储池只剩下约 1TB 的可用空间，随时可能进入只读模式。于是我买了一块全新的 10TB 硬盘（HGST HUH721010ALE600），插入 NAS 的空闲槽位，打算把存储池从 ~18TB 扩展到 ~27TB。

在群晖 存储管理器 中点击 存储池 1 → 添加硬盘，勾选新盘后，界面显示：

"预计容量：0 GB"

点击"应用"后，页面毫无反应，就像按钮坏了一样。

---

二、经过：一波三折的排查之路

第一阶段：发现 GPT 分区表损坏

SSH 登录 NAS 后，执行 fdisk -l 发现新盘被识别为 /dev/sdh（9.1 TiB），但系统报告 GPT 分区表存在错误。这意味着群晖无法正确读取这块盘的分区信息，GUI 自然算不出容量。

尝试 1：用 fdisk 重建 GPT

fdisk /dev/sdh
# 输入 g (新建 GPT) → w (写入)

执行后 fdisk -l 不再报错了，但回到 GUI 点击扩容——依然显示 0GB，依然没反应。

[!WARNING]
踩坑 #1：fdisk 只能重建分区表的"外壳"，但群晖需要的是符合 DSM 规范的特定分区结构（系统分区 8G + 交换分区 2G + 数据分区），光建一个空 GPT 表是不够的。

第二阶段：尝试 sfdisk 克隆分区布局

既然需要特定的分区结构，我尝试用 sfdisk 把正常工作的硬盘 sda 的分区布局克隆到 sdh 上：

sfdisk -d /dev/sda | sfdisk /dev/sdh

结果：报错 Please specify -z and -N。

加上参数再试：

sfdisk -d /dev/sda | sfdisk -z -N /dev/sdh

结果：依然报错 Please specify -z and -N。

[!WARNING]
踩坑 #2：群晖对标准 Linux 工具 sfdisk 做了深度定制（"魔改"），导致标准参数组合被拒绝执行。这条路彻底走不通。

第三阶段：dd 物理抹除 + 重启

既然工具不行，我怀疑是磁盘上残留的旧 RAID 元数据（Superblock）在作祟。于是用 dd 对硬盘首尾各 100MB 进行了物理级别的清零：

# 抹除开头
dd if=/dev/zero of=/dev/sdh bs=1M count=100 conv=notrunc
# 抹除结尾
sectors=$(blockdev --getsz /dev/sdh)
dd if=/dev/zero of=/dev/sdh bs=1M count=100 seek=$(( (sectors/2048) - 100 )) conv=notrunc

然后重启 NAS。重启后进入 GUI——依然无法扩容，点击应用没反应。

[!WARNING]
踩坑 #3：dd 抹除确实清除了残留数据，但问题的根源不在磁盘上，而在群晖的系统服务上。

第四阶段：抓到了真正的元凶——系统服务崩溃

我使用 tail -f /var/log/messages 实时监控日志，然后在 GUI 上点击"应用"。终端里立刻弹出了致命证据：

coredump: Process SYNO.Storage.CG dumped core on signal [6].
Cmdline [synoscgi_SYNO.Storage.CGI.Pool_1_estimate_size]

coredump: Process SYNO.Storage.CG dumped core on signal [6].
Cmdline [synoscgi_SYNO.Storage.CGI.Pool_1_expand_by_add_disk]

真相大白：群晖的存储管理后台进程 synoscgi 在计算新盘容量和执行扩容操作时，直接发生了 SIGABRT 崩溃（核心转储）。这是 DSM 的一个软件 Bug，跟硬盘本身无关，跟槽位也无关（我换了好几个不同的物理槽位，结果都是崩溃）。

[!CAUTION]
踩坑 #4：之所以 GUI 上"点了没反应"，是因为后台程序已经闪退了。网页前端没有收到任何响应，所以看起来像是按钮坏了。这个 Bug 在群晖官方论坛上有零星报告，但没有官方修复。

第五阶段：放弃 GUI，命令行手动合位

既然 GUI 彻底废了，我决定完全绕过它，直接用底层命令完成全部操作。

换了槽位后，设备名从 sdh 变成了 sde。通过交叉比对 fdisk 和 mdstat 确认：

fdisk -l 2>/dev/null | grep "9.1 TiB"
# 输出：sda, sdb, sdd, sde（四块 10T 盘）

cat /proc/mdstat | grep sde
# 无输出 → sde 不在任何阵列中 → 它就是新盘

[!IMPORTANT]
核心方法论：新盘的每个分区必须和老盘完全一致，否则 mdadm 会拒绝合入。所以在对新盘做任何操作之前，必须先查清老盘的分区大小，作为"标准答案"来对照。

用 fdisk 查看阵列中任意一块正常工作的老盘（这里以 sda 为例）：

fdisk -l /dev/sda | head -20

输出结果：

Device        Start         End     Sectors  Size Type
/dev/sda1      8192    16785407    16777216    8G Linux RAID
/dev/sda2  16785408    20979711     4194304    2G Linux RAID
/dev/sda3  21257952 19532682399 19511424448  9.1T Linux RAID

把这三个分区的大小记下来（8G、2G、9.1T），这就是新盘必须达到的"标准答案"。

有了"标准答案"后，用群晖原生工具查询老盘使用的布局索引号：

synopartition --check /dev/sda
# 输出：partition layout is version 9, list index is 15.

[!CAUTION]
踩坑 #5（最致命的坑）：我第一次跳过了第 5.2 步，凭经验猜测索引是 12，直接执行了 synopartition --part /dev/sde 12。结果生成的系统分区只有 2.4GB，而老盘的分区是 8GB。执行 mdadm --add 时报错 not large enough to join array。如果我一开始就先查了老盘的分区大小，就能立刻发现不对劲。正确的索引号是 15，每台机器可能不同，必须用 --check 查询，绝不能猜。

synopartition --part /dev/sde 15

fdisk -l /dev/sde | head -20

逐项比对（这一步决定了后续 mdadm 能否成功）：

分区	sda（老盘·标准答案）	sde（新盘·实际结果）	匹配
分区 1（系统，md0 用）	8G	8G	✅
分区 2（交换，md1 用）	2G	2G	✅
分区 3（数据，md2 用）	9.1T	9.1T	✅

只有三项全部 ✅ 才能继续下一步。如果任何一项大小不一致，说明索引号选错了，需要重新执行 synopartition --part 并换一个索引。

mdadm --manage /dev/md0 --add /dev/sde1   # 系统分区归队
mdadm --manage /dev/md1 --add /dev/sde2   # 交换分区归队
mdadm --manage /dev/md2 --add /dev/sde3   # 数据分区归队
mdadm --grow /dev/md2 --raid-devices=4    # 从 3 盘扩展为 4 盘

执行 cat /proc/mdstat，看到：

md2 : active raid5 sde3[3] sda3[0] sdd3[2] sdb3[1]
      ... [4/4] [UUUU]
       reshape=DELAYED
md0 : ... recovery = 35.2% ...
md1 : ... recovery = 62.7% ...

[UUUU] 四盘全亮！ 系统分区正在快速同步，数据分区的 reshape 等待同步完成后自动启动。

---

三、附带成果：空间回收 + LUN 扩容

在排查扩容问题的过程中，还顺手解决了两个相关问题：

3.1 找回"消失"的 2TB 空间

删除了大量文件后，NAS 的可用空间三天都没有增加。通过 btrfs subvolume list -s /volume1 发现了一个 iSCSI LUN 的历史快照，它像锚一样锁住了所有被删除的数据块。在 Snapshot Replication 中删除该快照后，立即回收了 3TB 空间。

3.2 Windows 端 LUN 扩容

在 NAS 端将 iSCSI LUN 从 500G 扩容到 1TB 后，Windows 里仍然显示 500G。通过 磁盘管理 → 重新扫描磁盘 → 扩展卷，成功将分区扩展到 1TB。

---

四、踩坑总结

#	踩坑点	现象	根因	正确做法
1	fdisk 重建 GPT	GUI 仍显示 0GB	空 GPT 不符合 DSM 分区规范	用 synopartition
2	sfdisk 克隆分区	报错 Please specify -z and -N	群晖魔改了 sfdisk	用 synopartition
3	dd 抹除 + 重启	GUI 仍无法扩容	问题在系统服务而非磁盘	查日志定位真因
4	GUI 点击无反应	看似按钮失灵	synoscgi 进程崩溃 (Coredump)	放弃 GUI，用命令行
5	分区索引选了 12	mdadm 报 not large enough	每台机器的索引号不同	先 --check 再 --part
6	换了多个物理槽位	问题依旧	是软件 Bug 不是硬件问题	不需要换槽位

---

五、最终结果

• ✅ 存储池 1 已从 3 盘 RAID5 扩展为 4 盘 RAID5
• ✅ 群晖 GUI 显示"正在后台优化...0.04%（剩余：2 天 13 小时）"
• ✅ 预计完成后，存储池容量将从 ~18TB 扩展到 ~27TB
• ✅ 空间回收成功找回 3TB
• ✅ iSCSI LUN 成功从 500G 扩容到 1TB

---

六、关键命令速查

# 1. 查询正确的分区布局索引（必做！）
synopartition --check /dev/sda

# 2. 对新盘执行分区（将 15 替换为你查到的索引）
synopartition --part /dev/sde 15

# 3. 加入阵列
mdadm --manage /dev/md0 --add /dev/sde1
mdadm --manage /dev/md1 --add /dev/sde2
mdadm --manage /dev/md2 --add /dev/sde3
mdadm --grow /dev/md2 --raid-devices=4

# 4. 查看进度
cat /proc/mdstat

复盘感悟：这次扩容之所以折腾了两天，核心原因是过度信任 GUI。群晖的 GUI 在 99% 的场景下确实好用，但当你碰到那 1% 的系统级 Bug 时，命令行才是最后的救命稻草。synopartition 和 mdadm 这两个底层工具，才是群晖存储管理的"真正引擎"。

原文链接：file://afa9199402675605ac1cdd497b545585