Linux怎么查看具体的磁盘逻辑卷管理组中的坏块屏蔽记录

在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里重映射计数是否归零——这才是实际起效的屏蔽证据。