☰

设备缺少 LVM 元数据

tag-icon • tag-icon debian lvm mdadm debian-lenny
设备缺少 LVM 元数据

情况是这样的。我有一个 MD 设备 /dev/md0，它功能齐全，但似乎没有 LVM 元数据。就我所知，它不是卷组的一部分，也不会显示为物理卷。另一方面，它是一个启动分区，它可以毫无问题地完成此功能。我还可以让其中一个设备发生故障，然后重新添加它们，它会毫无问题地重建阵列。那我为什么要关心呢？嗯，每次我更新 grub 时，我都会收到一大堆“错误：未知的 LVM 元数据头”消息。这不是问题，但它让我很烦。

以下是一些详细信息：

# uname -a
Linux redacted 3.9-1-amd64 #1 SMP Debian 3.9.6-1 x86_64 GNU/Linux

# pvck /dev/md0
Could not find LVM label on /dev/md0

# mdadm --detail --scan
ARRAY /dev/md/0 metadata=1.2 name=redacted:0 UUID=Stuff
ARRAY /dev/md/1 metadata=1.2 name=redacted:1 UUID=Stuff
ARRAY /dev/md/2 metadata=1.2 name=redacted:2 UUID=Stuff
# lvscan -v
Finding all logical volumes
ACTIVE            '/dev/vg01/home' [232.83 GiB] inherit
ACTIVE            '/dev/vg01/storage' [3.87 TiB] inherit
ACTIVE            '/dev/vg00/root' [59.53 GiB] inherit

# pvdisplay -v
Scanning for physical volume names
--- Physical volume ---
PV Name               /dev/md2
VG Name               vg01
PV Size               4.09 TiB / not usable 512.00 KiB
Allocatable           yes (but full)
PE Size               4.00 MiB
Total PE              1073097
Free PE               0
Allocated PE          1073097
PV UUID               Stuff
--- Physical volume ---
PV Name               /dev/md1
VG Name               vg00
PV Size               59.53 GiB / not usable 4.93 MiB
Allocatable           yes (but full)
PE Size               4.00 MiB
Total PE              15239
Free PE               0
Allocated PE          15239
PV UUID               Stuff

# cat /proc/mdstat 
Personalities : [raid1] [raid6] [raid5] [raid4] 
md2 : active raid5 sdc1[0] sdf1[3] sde1[2] sdd1[1]
      4395406848 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
md1 : active raid1 sda2[0] sdb2[1]
      62423992 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sda1[2] sdb1[1]
      96244 blocks super 1.2 [2/2] [UU]
unused devices: <none>  

# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1011774,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=810888k,mode=755)
/dev/mapper/vg00-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1621760k)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/md0 on /boot type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg01-home on /home type ext4 (rw,relatime,stripe=384,data=ordered)
/dev/mapper/vg01-storage on /storage type ext4 (rw,relatime,stripe=384,data=ordered)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)

# file -k -s /dev/md0 /dev/sda1 /dev/sdb1
/dev/md0:  sticky Linux rev 1.0 ext4 filesystem data, UUID=redacted (needs journal recovery) (extents) (huge files)
/dev/sda1: sticky Linux Software RAID version 1.2 (1) UUID=redacted name=redacted:0 level=1 disks=2
/dev/sdb1: sticky Linux Software RAID version 1.2 (1) UUID=redacted name=redacted:0 level=1 disks=2

有什么方法可以解决这个问题还是我只能忍受它？

答案1

在设备上创建 PV 时，LVM 标签（默认情况下）位于第二个 512B 扇区中。如果设备是要安装 grub 的整个磁盘，那么这正是 grub 的 core.img 所在的位置。LVM 元数据（默认情况下每个磁盘有一个副本）位于标签之后，从第五个扇区开始。（可选的第二个元数据副本可以位于磁盘末尾。）该元数据大小默认为 255 个扇区。您可以使用选项将标签的默认位置更改为前 4 个扇区中的任何位置，--labelsector但这pvcreate似乎不够，因为 grub 的 core.img 似乎需要 MBR 之后的 62 个扇区。（MBR 占用第一个扇区并包含 grub 的 boot.img。）

可以链式加载 grub，使用 MBR 中的一个引导加载程序来加载位于磁盘上其他位置的 boot.img/core.img。通常“其他位置”是指卷引导记录中的第一个分区之前和 MBR 之后的空间 + 其他干扰数据。问题是 PV 的数据部分通常紧接着元数据部分开始。有一种--dataalignmentoffset选择pvcreate可以在这里腾出一些空间，但这种方法对读者来说可能是一种练习。

参见（grub2）：http://en.m.wikipedia.org/wiki/GNU_GRUB

参见（lvm2）：http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/physical_volumes.html

我建议解决这个问题的方法是，不要将整个设备用作 PV，而是在磁盘上创建一个分区。将其用作 LVM 的 PV。然后 PV/LVM 标签和元数据将位于分区的开头，而不是磁盘的开头。这样 MBR 之后（第一个分区之前）的 62 个扇区将可供 core.img 使用。

我要补充的是，GPT 给这些工作带来了麻烦，这一点我不太明白。[好吧，评论听起来很简单。]

相关内容