Linux如何查看LVM组坏块屏蔽记录

在Linux系统中，LVM（逻辑卷管理）组内并不存在“坏块屏蔽记录”这一概念。LVM本身不记录、不管理、也不屏蔽坏块，其核心职责是逻辑卷抽象。底层物理坏块必须由文件系统或硬盘固件处理。因此，使用vgdisplay或lvscan命令查询坏块屏蔽信息，并不会得到有效结果。

那么，坏块实际上被屏蔽在哪里？以下是详细说明。

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

LVM在块设备之上构建逻辑层，将物理卷（PV）组合为卷组（VG），再从中划分逻辑卷（LV）。但LVM无法感知扇区级别的故障：

• 不读写具体扇区，也不校验数据完整性。
• 不解析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超级块的badblocks inode（编号2）。后续的mkfs.ext4 -l或e2fsck -c会读取该记录。可通过dumpe2fs -h /dev/mapper/vgname-lvname | grep -i "bad"确认是否存在。
• 硬盘固件层（S.M.A.R.T.）：当坏块被重映射时，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中重映射计数是否归零——这才是实际起效的屏蔽证据。