badblocks不能直接扫描整块磁盘（如/dev/sdb），因其不识别MBR/GPT、分区表、LVM元数据等关键结构，-w模式下可能覆盖导致系统无法启动；必须针对已卸载的分区（如/dev/sdb1）操作，配合e2fsck -l标记坏块才能实现隔离。
badblocks 本身不能“全盘扫描坏道”——它只扫描你指定的设备或分区范围，且必须配合文件系统工具才能实现坏块隔离。直接对整块硬盘（如 /dev/sdb）运行 badblocks 风险极高，极易误伤分区表、引导扇区或LVM元数据，导致系统无法启动或逻辑卷损坏。
为什么不能直接对 /dev/sdb 扫描
整块磁盘设备（如 /dev/sdb）包含MBR/GPT、分区表、可能的LVM PV头、EFI System Partition等关键结构。badblocks 不识别这些布局，会把它们当普通数据块读写，尤其在 -w（写入测试）模式下，可能覆盖分区表或LVM元数据，造成不可逆破坏。
- 常见错误现象：
fdisk -l /dev/sdb突然显示“Invalid partition table”，或pvs报 “Failed to read physical extent” - 正确做法：永远针对**已确认的、未挂载的分区**（如
/dev/sdb1）操作 - 若需覆盖整盘物理扇区（极少见），应先用
dd if=/dev/zero of=/dev/sdb bs=4M status=progress彻底擦除，再重建分区——这不是坏道检测，而是报废前清理
如何安全地扫描一个分区的所有可用块
所谓“全盘扫描”，实际指扫描该分区从第一个用户数据块到最后一个块的完整地址空间。前提是分区已卸载、文件系统类型为 ext2/3/4：
- 先确认分区边界：
sudo dumpe2fs -h /dev/sdb1 | grep -E "(Block count|Block size)"，得到总块数和块大小 - 非破坏性扫描（推荐）：
sudo badblocks -nsv -c 64 /dev/sdb1 > /tmp/badblocks.txt
其中-n保证不改数据，-c 64每次处理64块提升效率，-s显示进度避免误判卡死 - 若需更高检出率（如怀疑写入路径故障），加
-p 3对疑似坏块重试3次：sudo badblocks -nsvp 3 /dev/sdb1 > /tmp/badblocks.txt - 绝对不要对根分区或/boot分区在线扫描；必须进Live USB环境操作
e2fsck -l 能否标记所有坏块
可以，但仅限 ext2/3/4 文件系统，且依赖坏块列表格式正确（纯数字每行一个，无空格/注释）：
-
sudo e2fsck -l /tmp/badblocks.txt /dev/sdb1会将每个数字解释为逻辑块号（logical block number），并写入文件系统的坏块 inode（通常是 inode 5） - 注意：该操作要求分区**未挂载**，且会短暂独占设备；若执行中被中断，文件系统可能处于 inconsistent 状态，需再次运行
e2fsck -f强制检查 - 不支持 XFS、Btrfs、NTFS；对 LVM 逻辑卷，目标是 LV 设备（如
/dev/mapper/vg0-lv_root），而非底层 PV - 验证是否生效：
sudo dumpe2fs -h /dev/sdb1 | grep "Bad blocks count"—— 输出值应等于cat /tmp/badblocks.txt | wc -l
扫描后发现坏块数量持续增长怎么办
这说明物理损伤正在恶化，badblocks + e2fsck -l 只是临时缓解，不是修复方案：
- 立即备份关键数据，停止向该盘写入新内容
- 运行
sudo smartctl -a /dev/sdb，重点看：Reallocated_Sector_Ct（已重映射扇区数）、Current_Pending_Sector（等待重映射的扇区）、UDMA_CRC_Error_Count（线缆/接口问题） - 若
Current_Pending_Sector> 0，尝试用sudo smartctl -t long /dev/sdb触发全盘自检，部分硬盘会在自检中自动重映射待定扇区 - SSD 完全不适用
badblocks；应改用smartctl或nvme-cli查看Media and Data Integrity Errors和Percentage Used
badblocks 的核心作用只是“报点”，真正让内核绕开坏扇区的是文件系统层的标记动作。跳过这一步，或者误扫整盘设备，结果就是白忙一场，甚至加速盘体崩溃。 
