Hey there! Let's walk through this odd LVM setup you've run into, figure out why it happened, what problems it causes, and how to fix it safely.

一、为什么会出现两个同名的app1逻辑卷？ #

这种情况几乎都是由误操作或元数据异常导致的，常见原因包括：

• 错误的扩展操作：最可能的场景是你（或之前的管理员）想扩展已有的app1 LV时，误用了lvcreate命令而非lvextend。虽然LVM通常会阻止在同一个VG下创建同名LV，但如果操作过程中断、元数据短暂不一致，或者使用了旧版本LVM的特殊参数，就可能出现这种重复条目。
• 元数据损坏：LVM的元数据文件（存放在/etc/lvm/backup/和/etc/lvm/archive/）如果出现损坏、冲突，比如意外断电导致元数据写入不完整，可能会让VG中出现重复的LV记录。
• 不当的备份恢复：如果之前对VG做过备份恢复操作，可能在恢复时没有清理旧的LV条目，导致新创建的LV和旧条目重复。

二、这种配置会带来哪些影响？ #

这个异常配置会引发不少问题，甚至威胁数据安全：

• 挂载混乱：两个LV都关联到/app1挂载点，系统挂载时可能随机选择其中一个生效，导致df -h显示的空间与实际不符，后续写入的数据可能存到错误的LV上。
• 数据丢失风险：如果误对未使用的LV执行格式化、删除操作，或者管理命令误操作到错误的LV，很可能会破坏/app1的实际数据。
• LVM管理异常：执行lvs、lvdisplay等命令时会出现混淆，后续的扩展、缩小LV等操作容易出错，甚至进一步损坏VG元数据。
• 空间浪费：从你的输出看，两个app1 LV都显示为699.99G，但实际sdb1(200G)+sdb3(500G)总容量才700G，说明元数据里的空间记录存在错误，VG的可用空间被错误占用。

三、修复步骤（务必先备份数据！） #

修复前一定要先备份/app1的所有数据，比如用rsync同步到外部存储：

rsync -av /app1 /path/to/external/backup/

1. 确认正在使用的LV #

你需要先搞清楚哪个LV是当前/app1实际在用的：

• 执行df -h /app1，查看挂载点对应的设备路径（比如/dev/mapper/APP-app1）。
• 用lvdisplay -c列出所有LV的详细信息，包括UUID、关联的物理卷，对比后找到和当前挂载设备匹配的LV。
• 也可以临时挂载两个LV到不同目录验证内容：

  # 先卸载当前的/app1（如果能卸载）
  umount /app1
  # 挂载第一个LV到临时目录
  mount /dev/APP/app1 /mnt/test1
  # 挂载第二个同名LV（系统可能会自动加后缀，比如APP-app1_1）
  mount /dev/APP/app1_1 /mnt/test2
  # 查看两个目录的内容，确认哪个是你实际在用的/app1数据
  ls /mnt/test1
  ls /mnt/test2
  

2. 移除无效的同名LV #

确认有效LV后，删除另一个无效的：

• 先卸载所有临时挂载的LV：

  umount /mnt/test1
  umount /mnt/test2
  

• 为了避免混淆，先给无效LV重命名：

  lvrename APP app1 app1_old
  

• 然后删除重命名后的无效LV：

  lvremove /dev/APP/app1_old
  

3. 修复并验证VG元数据 #

• 备份当前VG的元数据：

  vgcfgbackup APP
  

• 执行以下命令确认异常已修复：

  lvs  # 应该只显示一个app1 LV
  lsblk # 确认sdb1和sdb3只关联到一个app1 LV
  df -h /app1 # 挂载后确认空间显示正常
  

4. 重新挂载并验证数据 #

• 重新挂载/app1：

  mount /app1
  

• 检查数据完整性，确保和备份的内容一致。

备注：内容来源于stack exchange，提问作者pretty.chloe.anne