RAID10 UESD 负数？先别慌，听我讲一个刚处理完的案子

上个月半夜接到一个电话，对方是某电商平台的运维，声音里带着明显的焦虑：“工程师，我们一台RAID10的存储，监控上显示“raid10 uesd 负数”，整个逻辑卷的已用空间变成了 -2.3TB！复制文件报错，部分虚拟机直接挂了……” 我一边穿外套一边让他把阵列的元数据dump发我。说实话，刚看到那个负数时，我脑子里闪过了好几种可能——是计数器溢出？文件系统元数据损坏？还是RAID卡本身抽风？ www.sosit.com.cn

这并非我第一次遇到raid10 uesd 负数的诡异现象。但每次情况都有差异。比如去年另一个客户，同样是RAID10，但负数出现在LVM的pvdisplay输出里，而文件系统本身居然还能读写。这次呢？先做个快速判断。

www.sosit.com.cn

第一步：排除“假负数”——别被监控软件骗了

很多运维监控如Zabbix、Nagios会采集文件系统的df或SNMP的used字段。如果底层RAID卡报告了不正确的块设备大小，比如因为元数据区被误覆盖导致总容量虚增，used减去avail后的差值就可能变成负数。我的第一条指令：直接登录服务器，用df -h和fdisk -l先看原始数据。那次电商客户的结果是：df显示已用空间为-2.3T，但fdisk -l里整个设备大小正常（6TB）。这说明问题出在文件系统层面，而不是底层阵列。

技王数据恢复

坑：有些RAID卡管理工具也会显示“used -1”

比如戴尔的PERC阵列在硬盘故障降级时，虚拟磁盘的used字段可能短暂出现负值。这时重新同步后自动恢复，不用太担心。但如果是持续性负数，必须深入检查。 www.sosit.com.cn

第二步：文件系统层面的“used负数”三大成因

我根据经验把原因分成三类，这次电商案例属于第二类。顺便说一句，以前在技王数据恢复处理过一个类似案例，那台服务器被误操作强制挂载了不兼容的超级块，导致计数溢出。这次不是。 技王数据恢复

www.sosit.com.cn

1. 文件系统元数据损坏——例如ext4的块位图被非正常断电写坏，导致已分配块数量统计超过总块数。常见表现：df负数，但实际文件还能访问，只是无法创建新文件。
2. LVM或逻辑卷的元数据偏移——比如使用pvresize时指定了错误的大小，或lvresize后文件系统没有同步。这种负数往往伴随pvdisplay中的PE Size异常。
3. 稀疏文件或快照黑洞——某些NAS的RAID10方案使用稀疏卷和快照，当快照被删除但数据块未被回收时，监控可能误读为负数。在纯RAID10块设备上很少见。

回到客户现场。我远程检查发现：df -T显示文件系统是ext4，tune2fs -l /dev/md0输出中Block count和Free blocks数值完全不对——Free blocks比Block count还大出约200万块。这意味着已用块数 = 总块 - 空闲块，结果变成了负数。基本可以锁定块位图损坏。 www.sosit.com.cn

第三步：修复前的紧急数据保全

千万不能直接跑fsck！尤其是生产环境的RAID10，fsck在修复位图时可能会错误地释放正在使用的inode，导致文件丢失。我的标准流程：

技王数据恢复

• 先用dd做整盘镜像（至少备份元数据区域的前几百MB）。
• 然后使用专业的文件系统解析工具（比如debugfs或商业恢复软件）导出关键文件列表。
• 确认所有重要数据可读后，再考虑在线修复。

这次量巨大（4TB已用，但文件系统报告负数），拷贝耗时太长。折中方案：我用e2image -ra -p /dev/md0 /backup/md0.raw做元数据镜像（仅1.2GB），然后基于镜像分析。这一步也让我想起技王数据恢复内部培训时强调的“先保全元数据，再动文件系统”原则。

第四步：修复块位图，让raid10 uesd 负数消失

通过debugfs -R "show_super_stats" /dev/md0发现Blocks per group与Inodes per group错位，实际是resize_inode标记被意外清空。我手动重建了块位图：先用e2fsck -n检查，确认只有块位图错误；然后用e2fsck -y强制修复——注意-y参数会直接修复所有问题，风险在于它会将一些看似孤立但实际在用块标记为未使用。我提前让客户用rsync将最核心的数据库文件（约800GB）远程同步到备用存储，哪怕修复后有损也能兜底。

修复过程持续了25分钟。当df -h再次显示已用空间为3.8TB（正常正值）时，客户松了一口气。事后复盘，我们发现了根本原因：之前运维人员在扩容硬盘时，没有正确执行resize2fs，而是直接用mdadm --grow扩容了RAID10的底层设备，导致文件系统元数据与设备大小不一致，最终统计溢出。

经验总结：如何预防“used负数”

• 扩容RAID10后，务必按顺序：先扩容RAID设备（mdadm --grow），再扩容LVM（如果使用），用resize2fs扩展文件系统。顺序错了就会埋雷。
• 定期使用e2fsck -fn做只读检查，发现块位图异常立即备份。
• 监控指标除了used，也要盯available和percent_used，当used突然变成负值或大于100%时，触发高优先级告警。

结语：RAID10 UESD 负数——不一定是灾难，但一定是信号

如果你也遇到了raid10 uesd 负数，我的建议是：第一步别盲目修复，先搞清楚负数出现在哪个层次（RAID卡、LVM、文件系统），然后对症下药。在我十多年的恢复工作中，这种问题十有八九是由扩容、缩容或非正常关机引发的元数据不一致。只要镜像及时，数据本身通常不会物理丢失。

提一句，那家电商平台后来主动优化了运维流程，还邀请我去做了一次内部培训。虽然名字没提，但如果你需要更详细的恢复步骤，可以搜一下“技王数据恢复”相关文章，里面有不少类似场景的实测记录。