Device Mapper 与 LVM 设备路径关系
本页用于解释挂载点显示为
/dev/mapper/...时应如何追溯存储层次。来源中的示例配置未在目标环境复现。
从挂载点追到物理卷
常见的 LVM 层次是 磁盘或分区 → PV → VG → LV → 文件系统 → 挂载点。PV 是加入 LVM 的物理卷；VG 汇集一个或多个 PV 的可分配空间；LV 从 VG 获得逻辑空间。device-mapper 在内核中提供块设备映射，LVM2 借它呈现 LV。
/dev/mapper/<映射名> 通常是指向某个 /dev/dm-N 的设备别名。对于 LVM，/dev/<VG>/<LV> 往往也指向同一逻辑卷；dm-N 编号可能随启动或设备发现顺序变化，不宜作为持久标识。/dev/mapper 里还可能是加密、RAID 或多路径映射，看到该目录名不足以判定设备是 LVM。VG 或 LV 名称中的连字符会在 mapper 名称中转义，不能仅按文件名中的连字符拆分 VG 和 LV。
只读核查线索
| 问题 | 可观察的对象 |
|---|---|
| 挂载点实际使用哪个源设备和文件系统？ | findmnt -no SOURCE,FSTYPE,TARGET /目标挂载点 |
| 设备别名最终指向哪个映射设备？ | readlink -f /dev/mapper/目标映射名；再用 lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS 对照。 |
| 若确认为 LVM，该 LV 从哪些 PV 分配？ | pvs、vgs、lvs -o lv_path,lv_size,devices；多段或特殊 LV 还需逐段核查。 |
这些输出用于建立当前映射关系，不等于已验证备份、迁移或重装方案。
必须纠正的迁移推论
VG 可以包含多个 PV，LV 的物理 extents 可能分布在其中一个或多个 PV 上。在同一个 VG 中新建 LV、再把文件复制过去，不保证新 LV 落在另一块物理磁盘，也不能据此保证重装时数据安全。 必须按实际分配结果和目标设备边界核查，并独立验证备份、恢复与启动依赖；不能从路径名推断数据所在磁盘。
适用版本与待核查
- 来源提到较早的 Linux/device-mapper 背景，但未给出实际内核、LVM2 版本和卷类型；本页以常见线性 LV 为说明范围。thin、RAID、镜像、缓存和加密叠层需另行分析。
- 在隔离环境核对当前发行版的 udev 设备别名、连字符转义规则，以及多 PV、分段 LV 的
lvs输出。 - 涉及磁盘重装或数据迁移时，还需核对实际 PV 分配、引导分区、文件系统与恢复演练记录，另行形成操作方案。
关联：Linux、存储、GPT 与 LVM 扩容核查。