Linux查看磁盘坏道:badblocks扫描与修复详解

作者:技术拾光时间:2026-06-10 09:04:15浏览:150

谈及磁盘健康状态时,badblocks 工具是许多系统管理员的首选。但需要先明确一个核心概念:badblocks 本身并不具备“修复”坏道的能力,其主要职责在于检测和标记。真正让文件系统避开这些物理损伤的,是后续配合使用的 e2fsck 或 mkfs 命令。理解这一分工是正确使用该工具的前提。 ba

谈及磁盘健康状态时,badblocks 工具是许多系统管理员的首选。但需要先明确一个核心概念:badblocks 本身并不具备“修复”坏道的能力,其主要职责在于检测和标记。真正让文件系统避开这些物理损伤的,是后续配合使用的 e2fsck 或 mkfs 命令。理解这一分工是正确使用该工具的前提。

badblocks 检测前必须卸载设备

如果目标设备(例如 /dev/sda1)仍处于挂载状态,badblocks 将拒绝执行写入类测试。即便是只读测试,系统缓存也可能引发干扰,导致漏检。强行运行时最常见的错误提示为 Device or resource busy。这并非权限问题,而是内核层面的保护机制在起作用。

正确的操作流程如下:

  • 首先使用 mount | grep sda1 确认分区挂载状态。
  • 若已挂载,务必先执行 sudo umount /dev/sda1。
  • 对于系统盘等无法直接卸载的分区,需要借助 Live CD 或 Live USB 环境进行操作。
  • 此外,SSD 用户需注意:-w 写入测试模式会对 NAND 闪存寿命造成额外损耗,除非必要,否则不建议在生产环境的 SSD 上运行。

谨慎使用 -w 参数:写入测试等于数据清零

badblocks -w 参数影响较大,它会向每个扇区写入特定的测试模式(如 0x00、0xff),然后读取校验。该过程会彻底覆盖原有数据,且不可逆。即使只扫描部分区域,被扫描块上的所有文件也会遭到损坏。

因此,推荐按以下安全优先级顺序进行检测:

  • 首先执行只读检测探路:sudo badblocks -v -s /dev/sda1。
  • 若命令有输出(即发现坏块编号),再根据情况决定是否使用 -w 参数以强制触发硬盘重映射机制。
  • 使用 -w 前,必须百分百确认该分区无重要数据,或已完成完整备份。
  • 需明确的是,现代硬盘的 G-List(增长缺陷表)重映射通常在写入时自动触发,-w 仅模拟此动作来暴露问题,并不能真正“修复”物理损伤。

结果文件如何应用:e2fsck -l 是关键一步

许多人认为运行完 badblocks 即告完成,实则不然。badblocks 本身不会让文件系统主动避开坏道,它仅将检测到的坏块编号记录到一个文本文件(如 badsectors.txt)中。真正让这些信息生效的是后续的 e2fsck 命令。

假设已生成坏块列表:

sudo badblocks -v -o badsectors.txt /dev/sda1

接下来必须执行的关键步骤:

sudo e2fsck -l badsectors.txt /dev/sda1

此处有三个细节需留意:

  • e2fsck 同样要求设备处于未挂载状态,否则会报错 The filesystem is mounted。
  • 参数 -l 是小写字母 L,并非数字 1。输错会导致命令静默失败,坏块仍会被系统使用。
  • 若文件系统为 XFS 或 Btrfs,则 e2fsck 不适用,需改用对应工具(例如 xfs_repair 目前不支持直接导入坏块列表)。

4K 扇区硬盘必须加 -b 4096

这是当前最容易踩坑的地方。绝大多数新机械硬盘和 NVMe SSD 的物理扇区大小已为 4096 字节(即 4K),但操作系统为兼容性考虑,默认仍按 512 字节逻辑扇区处理。若未通过 -b 4096 参数明确指定物理扇区大小,badblocks 会将一个物理扇区错误地当作 8 个逻辑块检测,导致误报或漏报。

如何确认硬盘扇区大小?使用以下命令:

sudo fdisk -l /dev/sda | grep “Sector size”

若输出类似 Sector size (logical/physical): 512 bytes / 4096 bytes,则表明物理扇区为 4K,必须使用 -b 4096 参数。

一个兼顾物理层匹配和后续处理的常用命令组合如下:

sudo badblocks -v -b 4096 -s -o badsectors.txt /dev/sda1

该命令既确保检测基准正确,又生成可供 e2fsck -l 直接使用的坏块列表文件。

最后,需要建立这样一个认识:坏道检测不应当视为常规的“体检”项目,而更接近于一种“确诊”手段。日常运维中,重点关注 SMART 属性告警、系统 I/O 错误日志,或运行 dmesg | grep -i “ata\|nvme\|error” 捕捉早期线索,往往比定期全盘扫描更为高效和及时。