写洞（Write Hole）问题
RAID 5/6 更新一条带时，数据块与校验块是分批写入的，如果断电、死机或卡故障正好发生在这个窗口内，条带就会处于数据与校验互不一致的状态，这就是所谓的写洞。平时它不会立刻暴露，直到某块盘故障、系统按错误校验去恢复数据时，错误才会被固化进重建结果——表现就是重建完成但数据已经错了。
基本信息
| 成因 | 同一条带的数据写与校验写未能原子完成（掉电、死机、卡故障） |
|---|---|
| 后果 | 重建时按错误校验恢复，产生静默错误 |
| 高风险级别 | RAID 5 最严重，RAID 6 因有第二组校验相对缓和 |
| 缓解手段 | 带电池或电容的写缓存、整条带写、支持校验日志的存储栈（如 ZFS） |
| 防护前提 | 写缓存必须处于受保护状态，且策略为 Write-Back |
检查写缓存与保护状态
检查写缓存与保护状态
storcli /c0/v0 show all | grep -i -E "write|policy" # 当前写策略
storcli /c0/bbu show all | grep -i -E "state|Failed" # 电池状态
storcli /c0/cv show all # 超级电容状态
storcli /c0 show all | grep -i -E "Cache|Memory" # 缓存容量
# 定期做一致性检查（CC）也能把不一致提前暴露出来
storcli /c0/v0 start cc缓解手段对照
| 手段 | 作用 | 局限 |
|---|---|---|
| 带保护的写缓存 | 掉电时保住缓存数据，争取把条带写完 | 电池老化或策略为 Write-Through 时失效 |
| 整条带写 | 一次写覆盖整个条带，减少不一致窗口 | 依赖请求大小与对齐 |
| 一致性检查（CC） | 定期校验数据与校验是否匹配 | 发现时只能记录或修复部分错误 |
| ZFS 校验日志 | 以事务方式提交，避免写洞 | 需要直通盘与专用文件系统 |
掉电后的正确处置
- 先确认业务与数据状态，不要直接在阵列上重建
- 检查卡事件日志与阵列状态，确认是否存在未完成的后台任务
- 在业务低峰安排一次一致性检查，确认数据与校验是否匹配
- 有备份的先核对关键数据，再决定后续动作
RAID 5 掉电后先确认一致性检查已做或关键数据已有备份，再决定是否重建；带错误的阵列直接重建会把静默错误固化下来。