LVM本身不记录、不管理也不屏蔽坏块，因此vgdisplay或lvscan查不到坏块屏蔽信息；坏块屏蔽实际发生在文件系统层（如e2fsck -l写入ext4 superblock）或硬盘固件层（SMART重映射），需直接检查底层物理设备（如/dev/sdb2）的badblocks日志或smartctl输出确认。
Linux里没有“LVM组中坏块屏蔽记录”这种东西——LVM本身不记录、不管理、也不屏蔽坏块。 它只负责逻辑卷抽象，底层物理坏块必须由文件系统或硬盘固件处理。
为什么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无关：
-
文件系统层（ext4等）：用
e2fsck -l badsectors.txt /dev/mapper/vgname-lvname把坏块列表写入ext superblock的badblocksinode（编号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里重映射计数是否归零——这才是实际起效的屏蔽证据。
