☰

LVM：重启后PV丢失

tag-icon • tag-icon linux lvm
LVM：重启后PV丢失

我有一台带有多个 LVM 逻辑卷的服务器（Ubuntu 18.04）。例行重启后，其中之一不会回来。经过一番调查，这就是我所在的位置：

  • 物理磁盘是一个 iSCSI 设备，内核将其视为 /dev/sdc （没有错误且大小正确）

  • lvmdiskscan -v 在 /dev/sdc 上看到 PV

 
> lvmdiskscan -v
...
/dev/sdc [72.76 TiB] LVM 物理卷
  • blkid 返回 UUID，我也可以在 LVM 配置中找到该 UUID
...
/dev/sdc: UUID="fvUXXf-pVOF-EPnn-c8eg-tZ5S-iMVW-wsSFDy" TYPE="LVM2_member"

  • 该条目缺少系统上其他 LV 具有的 PARTUUID 条目。这是一个线索吗？我无法将这条信息与任何对我有进一步帮助的信息联系起来。

  • pvscan 不报告 /dev/sdc

  • pvdisplay 似乎不知道这个PV

> pvdisplay /dev/sdc
找不到物理卷“/dev/sdc”

谁能指出我正确的方向？

编辑以添加 pvck -t 的输出

pvck -t /dev/sdc
  测试模式：元数据不会更新，卷也不会被（取消）激活。
  在 /dev/sdc 上找到标签，扇区 1，类型=LVM2 001
  找到文本元数据区域：offset=4096，size=1044480

同样有用的是，这个 LV 最初是在 Ubuntu 14.04 上制作的，并且在 Ubuntu 18.04 上运行得非常好。

下面是 lvmdiskscan 的其他输出。此输出看起来与系统上其他 VG 的输出没有什么不同。 LV 首先看起来是孤立的，然后它们与 VG 关联，并且变得可用。但对于 r3vg 这不会发生。

lvm[7852]：从设备 /dev/sdc 读取标签
 lvm[7852]：打开/dev/sdc RO O_DIRECT
 lvm[7852]: /dev/sdc: 块大小为 4096 字节
 lvm[7852]: /dev/sdc: 物理块大小为 512 字节
 lvm[7852]: /dev/sdc: 在扇区 1 检测到 lvm2 标签
 lvm[7852]：lvmcache /dev/sdc：现在位于 VG #orphans_lvm2 (#orphans_lvm2) 中，mda 为 0。
 lvm[7852]: /dev/sdc: 找到 PV 标头扩展版本 2
 lvm[7852]：/dev/sdc：在 5632 大小 1015（在 4096 大小 1044480 的区域）找到 r3vg 的元数据（Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00）
 lvm[7852]：lvmcache 没有 VGID Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00 的 vgname“r3vg”的信息。
 lvm[7852]：lvmcache 没有 vgname“r3vg”的信息。
 lvm[7852]：lvmcache /dev/sdc：现在位于 VG r3vg 中，具有 1 mda。
 lvm[7852]：lvmcache /dev/sdc：VG r3vg：将 VGID 设置为 Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00。
 lvm[7852]: lvmcache /dev/sdc: VG r3vg: 将创建主机设置为 leitrim。
 lvm[7852]：lvmcache /dev/sdc：VG r3vg：存储的元数据校验和 0x54affad5，大小为 1015。
 lvm[7852]：关闭/dev/sdc
 lvm[7852]: /dev/sdc: 使用缓存大小 156250918912 扇区
 lvm[7852]：/dev/sdc [72.76 TiB] LVM 物理卷
 lvm[7852]：7个磁盘
 lvm[7852]：3个分区
 lvm[7852]：1个LVM物理卷整个磁盘
 lvm[7852]：2个LVM物理卷
 lvm[7852]：将 global/notify_dbus 设置为 1
 lvm[7852]：已完成：lvmdiskscan -dddddd

答案1

如果执行sudo vgscanand操作，LV 是否可以安装sudo vgchange -ay？如果这些命令导致错误，您可能遇到了不同的问题，并且应该在原始帖子中添加这些错误消息。

但是，如果 LV 在这些命令之后准备好安装，请继续阅读...

仅LVM 逻辑卷路径名（例如/dev/mapper/vgNAME-lvNAME）/etc/fstab不会向系统提供线索，表明在激活网络和 iSCSI 之前无法安装此特定文件系统。

如果没有该线索，系统将假定文件系统位于本地磁盘上，并会尝试尽早挂载它，通常是在激活网络之前，这对于 iSCSI LUN 来说显然会失败。因此，您需要以某种方式提供该线索。

一种方法是添加_netdev到该文件系统的挂载选项/etc/fstab。从这个 Ubuntu 帮助页面Ubuntu 似乎支持它。实际上，vgscan在尝试挂载任何标有_netdev.

另一种方法是使用 systemd 特定的挂载选项x-systemd.requires=<iSCSI initiator unit name>。通过推迟挂载该文件系统的任何尝试，直到成功激活 iSCSI 启动器，应该可以实现相同的效果。

当 iSCSI 启动器激活时，它将自动使任何配置的 LUN 可用，并且当它们变得可用时，LVM 应自动激活其上的任何 VG。因此，一旦您推迟了挂载尝试，就足够了。

缺少 PARTUUID 表明磁盘/LUN 没有 GPT 分区表。因为它实际上根本没有任何分区表/dev/sdc。TYPE="LVM2_member"理论上，它应该不会对 Linux 造成任何问题，但我还没有亲自测试过具有 iSCSI 存储的 Ubuntu 18.04 系统，因此不能绝对确定。

没有分区表的磁盘/LUN 的问题是，其他操作系统不会将 Linux LVM 标头识别为磁盘正在使用的标志，并且会在很少的提示下愉快地覆盖它。如果您的 iSCSI 存储管理员意外地将与您对应的存储 LUN 提供/dev/sdc给另一个系统，则可能会发生这种情况。

您应该在与丢失的 VG 对应的目录中找到 LVM 配置备份文件/etc/lvm/backup，并读取它以找到丢失的 PV 的预期 UUID。如果它与blkid报告相符，请要求您的存储管理员仔细检查他/她最近的工作是否存在上述错误。如果发现 PV 已被其他系统覆盖，则 LUN 上的任何剩余数据都可能或多或少地损坏，最好从备份中恢复它......一旦您获得新的，保证无冲突来自 iSCSI 管理员的 LUN。

如果事实证明 的实际 UUID/dev/sdc与预期不同，则有人可能不小心以pvcreate -f /dev/sdc某种方式运行了。如果这是唯一已完成的事情，那么修复起来相对容易。 （笔记：检查man vgcfgrestore章节替换物理卷有关更新的说明 - 您的 LVM 工具可能比我的新。）首先恢复 UUID：

pvcreate --restorefile /etc/lvm/backup/<your VG backup file> --uuid <the old UUID of /dev/sdc from the backup file> /dev/sdc

然后恢复VG配置：

vgcfgrestore --file /etc/lvm/backup/<your VG backup file> <name of the missing VG>

此后，应该可以激活 VG，如果没有造成其他损坏，则随后挂载文件系统。

答案2

在阅读了 telcoM 的评论并进一步挖掘日志和手册页后，我现在可以回答我自己的问题了。

由于某种原因，有关 PV /dev/sdc 所属 VG 的信息在重新启动期间丢失，并且再也没有回来。

我不完全理解该解决方案（也许理解的人可以添加一些细节），但以下方法有效。第一的

> vgscan --缓存
  使用元数据类型 lvm2 找到卷组“r3vg”

找到我的 VG 配置。现在PV又被知道了

> 光伏发电
  /dev/sdc r3vg lvm2 a-- 72.76t 26.39t

LV 也再次已知但不活跃

> lvscan
   不活动的“/dev/r3vg/p0”[46.37 TiB]继承

最后

> lvchange -ay r3vg/p0

把它带回来。

我不清楚为什么重新启动后 VG 配置没有被选取。如果有人有任何建议，请在评论中添加。

相关内容