在Linux系统中，您无法直接找到所谓的“LVM组中坏块屏蔽记录”——LVM本身并不记录、管理或屏蔽坏块。它的核心职责是逻辑卷抽象，底层物理坏块必须由文件系统或硬盘固件来处理。因此，如果您试图通过vgdisplay或lvscan来查询坏块屏蔽信息，结果注定是徒劳的。

那么，坏块究竟去了哪里？它被屏蔽在了什么地方？

为什么vgdisplay或lvscan查不到坏块屏蔽信息

LVM本质上是在块设备之上构建的一层逻辑架构。它将物理卷（PV）组合成卷组（VG），再从卷组中划分出逻辑卷（LV）。但关键在于，它完全无法感知扇区级别的细微故障： - 不参与具体扇区的读写，不校验数据完整性 - 不解析badblocks的输出，也不调用e2fsck -l - 即使PV所在磁盘已经出现坏块，LVM仍会照常分配PE，直到IO操作失败才报错（例如device-mapper: reload ioctl failed或end_request: I/O error）

因此，在vgdisplay、pvs、lvs的输出中，您永远找不到类似“已屏蔽坏块数”这样的字段。这并非LVM的职责范围。

坏块实际在哪被记录和屏蔽

屏蔽动作发生在两个层级，而且都与LVM无关：

• 文件系统层（ext4等）：使用e2fsck -l badsectors.txt /dev/mapper/vgname-lvname将坏块列表写入ext超级块（superblock）的badblocks inode（编号2）；后续的mkfs.ext4 -l或e2fsck -c会读取这份记录。您可以通过dumpe2fs -h /dev/mapper/vgname-lvname | grep -i "bad"来确认是否存在。
• 硬盘固件层（S.M.A.R.T.）：当坏块被重映射（reallocated）时，smartctl -a /dev/sdb会显示Reallocated_Sector_Ct或Current_Pending_Sector非零；这是硬件自动完成的，LVM和文件系统都无法察觉。

怎么确认LVM底层PV是否含已屏蔽坏块

您需要绕过LVM，直接查询其物理卷所依赖的原始设备：

• 先定位PV对应的真实设备：pvs -o +pv_uuid,vg_name → 找到PV列（例如/dev/sdb2）
• 检查该设备是否有通过badblocks标记过的坏块文件：ls /var/log/badblocks_*.txt 或您自定义的保存路径
• 验证文件系统是否已加载该列表：e2fsck -n -v /dev/sdb2 2>&1 | grep -i "bad block"（加上-n参数进行只读检查）
• 查看S.M.A.R.T.是否已执行重映射：smartctl -A /dev/sdb | awk '/Reallocated|Pending/ {print $1,$2,$10}'

注意：/dev/mapper/vgname-pvname这类设备名是LVM内部路径，不能直接传递给badblocks或e2fsck——它们必须作用于底层物理分区（例如/dev/sdb2）。

真正要盯住的关键点

很多人陷入“以为LVM能管理坏块”的误区，结果忽略了最危险的环节： - badblocks输出的坏块列表没有传递给e2fsck -l，文件系统仍在向坏扇区写入数据 - PV设备挂载为LV后，smartctl显示的Reallocated_Sector_Ct持续上升，但LVM毫无反应 - 使用dd if=/dev/zero of=/dev/mapper/vg-lv bs=4k测试时突然出现IO错误，才发现问题已经渗透到LV层

所以，不要寻找“LVM里的坏块记录”，而是去检查/dev/sdXN本身是否被e2fsck -l标记过，以及smartctl中的重映射计数是否归零——这才是实际起作用的屏蔽证据。