一、事情的起因

昨天下午5点，一台 ESXi 服务器上的 RAID 阵列报警，一块 16TB 硬盘挂了。换上新盘后，开始重建（Rebuild）。

今天上班后8点多一查进度：

Progress%: 2%
Estimated Time Left: 25 Days 4 Hours 42 Minutes

发到群里后客户表示："这个也太慢了吧。"

我回了一句："这个的快慢，貌似没啥人为可调的吧。"

真的是这样吗？

二、先别急着认命，查一下再说

2.1 确认重建速率

登录 ESXi Shell，进 StorCLI 目录：

cd /opt/lsi/storcli/
./storcli /c1 show rebuildrate

输出：

Ctrl_Prop   Value
------------------
Rebuildrate 30%

破案了！默认重建速率只有 30%。

这就是重建慢到25天的直接原因。LSI/Broadcom RAID 卡默认把重建速率设得很保守，目的是优先保障业务 I/O。但在这个场景下，显然不合理。

2.2 评估业务负载

在调整之前，先确认这台 ESXi 上的虚拟机 I/O 压力：

esxcli storage core device stats get
esxcli storage vmfs extent list

结果显示：

当前负载以读为主，重建主要是写操作到替换盘，两者 I/O 路径不完全冲突。加上这是 RAID 重建（后台顺序写），对随机读业务影响有限。另外只是二级存储，目前没有生产跑在上面。

结论：可以安全上调重建速率。

三、动手调整：从30%拉到100%

既然不跑生产，没啥影响，直接拉满：

./storcli /c1 set rebuildrate=100

验证生效：

./storcli /c1 show rebuildrate

输出：

Ctrl_Prop   Value
------------------
Rebuildrate 100%

四、效果观察：ETA 的过山车之旅

调完 100% 后，预计时间的变化堪称"过山车"：

为什么 ETA 跳来跳去？

RAID 控制器的 ETA 算法是动态滚动估算，基于最近一段时间的瞬时写入速度外推。但这个速度极不稳定，原因有三：

1. 1. 重建初期的"热身"阶段：刚换盘开始重建时，控制器需要初始化新盘、建立映射表，这个阶段写入速度极低，所以估算出 56 天这种离谱数字。等进入稳定顺序读写后，估算会回落。
2. 2. 外圈 vs 内圈速度差异：HDD 外圈线速度高（250MB/s），内圈线速度低（100MB/s）。RAID 重建是从外到内顺序写的，控制器在不同位置采样，会得到截然不同的速度，ETA 随之跳动。
3. 3. 整数精度问题：StorCLI 只显示整数百分比，2% 可能是 2.01 也可能是 2.99。因此不能仅凭两次查看之间的时间差来计算真实速度。

五、深入排查：为什么 100% 还是不够快？

5.1 排除后台任务干扰

./storcli /c1 show patrolread
./storcli /c1 show cc

结果：

• • Patrol Read: Stopped
• • Consistency Check: Stopped

后台任务没有干扰。

5.2 检查硬盘健康状态

./storcli /c1/eall/sall show all | grep -iE "State|Error|Fail|Bad|Predict|Media|Smart"

结果：所有 12 块盘（s0-s11）都是健康状态：

• • Media Error Count = 0
• • Other Error Count = 0
• • Predictive Failure Count = 0
• • S.M.A.R.T alert = No

硬盘没有问题。

5.3 查看 RAID 配置详情

./storcli /c1/vall show all
./storcli /c1/dall show all

关键发现：

这才是真相！

RAID 6 重建的数学复杂度：

• • 需要读取 10 块在线盘 的全部数据
• • 需要计算 P + Q 双校验（比 RAID 5 多一倍计算量）
• • 总读取量 ≈ 10 × 16TB = 160TB
• • 加上校验计算和写入新盘

SATA HDD 的实际顺序读取速度：

• • 外圈：约 250 MB/s
• • 内圈：约 100-150 MB/s
• • 平均：约 180 MB/s

160TB ÷ 180MB/s ≈ 246小时 ≈ 10.3天（纯读取，不含校验和写入）

加上校验计算、写入、以及 SATA 总线共享带宽的争用，8-17 天是非常合理的物理上限。

5.4 重建盘的详细信息

./storcli /c1/e134/s0 show all

输出关键信息：

• • 型号：MG09ACA16TE（东芝 16TB SATA HDD）
• • 容量：14.551 TB
• • 接口：SATA 6.0Gb/s
• • 物理扇区：4 KB，逻辑扇区：512 B（512e）
• • Write Cache：Disabled（盘级写缓存关闭）
• • Media Error Count：0
• • Predictive Failure Count：0

注意：这里的 Write Cache = Disabled 是盘级写缓存，而 VD 级别的 WriteBack 是RAID 卡缓存，两者不同。RAID 卡缓存已开启，但盘级缓存关闭对重建性能有一定影响。

六、时间线复盘与真实速度估算

6.1 完整时间线

6.2 真实速度计算

关于 2% → 3% 的耗时：

由于 StorCLI 只显示整数百分比，我们无法精确知道 2% 是何时达到的。已知：

• • 昨天 17:00 开始重建时是 0%
• • 今天 08:40 查看时已经是 2%
• • 09:35 查看时仍是 2%
• • 09:49 查看时变为 3%

因此，2% 这个状态至少从 08:40 持续到 09:35（至少 55 分钟），但实际可能从昨天 17:00 之后不久就已经达到 2% 了。由于中间缺少数据点，无法精确计算 2% → 3% 的真实耗时。

3% → 4% 的耗时：

• • 09:49 是 3%
• • 14:00 是 4%
• • 耗时约 4 小时 11 分钟（12点时看的时候还是3%，2点上班后4%，可能也有误差）

按这个速度外推：

• • 剩余 96% × 4.18 小时 ≈ 401 小时 ≈ 16.7 天

但 ETA 显示 8 天 22 小时，说明控制器认为当前瞬时速度比实际平均速度快，或者当前正处于外圈高速区。

真实速度可能在 10-12 天左右，具体取决于后续是否进入内圈慢区。由于数据点有限，这个估算也存在不确定性。

七、知识点总结

7.1 StorCLI 常用命令速查

# 查看重建进度
./storcli /c1/e134/s0 show rebuild

# 查看重建速率
./storcli /c1 show rebuildrate

# 设置重建速率（0-100）
./storcli /c1 set rebuildrate=100

# 查看 Patrol Read 状态
./storcli /c1 show patrolread

# 查看一致性检查状态
./storcli /c1 show cc

# 查看虚拟磁盘详情
./storcli /c1/vall show all

# 查看磁盘组详情
./storcli /c1/dall show all

# 查看所有硬盘状态
./storcli /c1/eall/sall show all

7.2 RAID 重建速率调整原则

7.3 RAID 6 重建慢的深层原因

1. 1. 双校验计算：RAID 6 需要计算 P 和 Q 两个校验值，计算量是 RAID 5 的两倍
2. 2. 大量数据读取：需要读取所有在线盘的数据（本例中 10 块盘 × 16TB = 160TB）
3. 3. SATA 总线瓶颈：12 块盘共享 SATA 带宽，重建时大量并发读取导致总线饱和
4. 4. HDD 物理极限：大容量 SATA 盘的外圈/内圈速度差异大，重建是从外到内顺序写的
5. 5. 无盘级写缓存：MG09ACA16TE 的 Write Cache 为 Disabled，每次写入都要等物理磁头落盘

7.4 ETA 跳动的解释

• • 初期不稳定：重建开始时的"热身"阶段，速度采样不准确
• • 位置差异：HDD 外圈快、内圈慢，不同位置的瞬时速度差异大
• • 动态修正：控制器会根据最近一段时间的实测速度不断修正估算值
• • 整数精度：StorCLI 只显示整数百分比，小数位的变化看不到，不能仅凭查看间隔计算真实速度

八、最终结论

"这个的快慢，貌似没啥人为可调的吧"——这句话不完全准确。

通过将 rebuildrate 从 30% 调到 100%，预计重建时间从 25天 降到了 8-9天，这是实实在在的人为优化。

但 100% 之后，速度就触及了物理极限：

• • RAID 6 双校验的数学复杂度
• • 12 块 16TB SATA HDD 的带宽瓶颈
• • 160TB 数据读取 + 校验计算 + 16TB 写入的物理耗时

8-12 天就是这个硬件组合的物理极限，rebuildrate 调到 100% 已经是极限操作了。

如果还想更快，只能：

1. 1. 换成 SAS 盘（速度提升有限）
2. 2. 换成 SSD（成本极高）
3. 3. 降级到 RAID 5 或 RAID 10（牺牲容错能力）

不跑生产已经是万幸，100% 挂着让它慢慢啃吧。

运维心得：遇到问题先别认命，查配置、看日志、动手试。很多时候"不可调"只是默认参数的限制，而不是物理极限。但调到极限后，就要尊重物理规律，急也没用。另外，看进度时别被整数百分比骗了，StorCLI 的精度限制会让你的速度估算偏差很大。

本文基于真实运维场景记录，如有雷同，说明你也踩过 RAID 重建的坑。