fstab 中的 UUID + 在哪些情况下我们不能在 fstab 中配置 UUID

fstab 中的 UUID + 在哪些情况下我们不能在 fstab 中配置 UUID

讨论 - 我们有 redhat linux 机器,我的问题是关于 /etc/fstab 文件中的 UUID 配置,在这种情况下 UUID 会给操作系统带来风险

据我了解,如果使用软件 RAID1,我们不得在 /etc/fstab 中使用 UUID。

为什么?因为 RAID 卷本身和镜像的第一个元素将看起来具有相同的文件系统 UUID。如果镜像损坏或由于任何其他原因 md 设备在启动时未启动,系统将安装任何随机的底层磁盘,从而破坏您的镜像。

所以我的问题是

我们的 RAID 级别(数字)是多少一定不UUID 在 fstab 中吗?

有关袭击级别的信息 -https://en.wikipedia.org/wiki/Standard_RAID_levels

答案1

我们将继续在 ArchLinux 和 mdadm 上进行测试。但首先这对于基于分区的阵列来说并不重要,因为成员分区有自己的 UUID,因此理论上这仅适用于整个磁盘成员。

TL;DR:即使对于旧的元数据块,这也不是一个真正的问题。这可能是我不知道的旧软件中的一个错误。但它不会影响现代的 ArchLinux。

#uname -sr
Linux 4.14.7-1-ARCH

#modprobe raid1

#mdadm --create --verbose /dev/md0 --metadata 0.9 --level=mirror --raid-devices=2 /dev/sdb /dev/sdd
mdadm: size set to 102336K
mdadm: array /dev/md0 started.

#cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdd[1] sdb[0]
102336 blocks [2/2] [UU]

unused devices: <none>

#mdadm --detail --scan >> /etc/mdadm.conf

fdisk /dev/md0
lsblk /dev/md0
NAME      MAJ:MIN RM   SIZE  RO TYPE MOUNTPOINT
sdb         8:16   0    100M  0 disk
└─md0       9:0    0    100M  0 raid1
  └─md0p1 259:0    0   98.9M  0 md 
sdd         8:48   0    100M  0 disk
└─md0       9:0    0    100M  0 raid1
  └─md0p1 259:0    0   98.9M  0 md 
md0         8:0    0    100M  0 raid1
└─sda2      8:2    0   98.9M  0 md

mdstat -> [UU]

#blkid /dev/md0
/dev/md0: PTUUID="d49d8666-e580-8244-8c82-2bc325157e66" PTTYPE="gpt"
#blkid /dev/sdd
/dev/sdd: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"
#blkid /dev/sdb
/dev/sdb: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"

#mkfs.ext4 /dev/md0p1
mke2fs 1.43.7 (16-Oct-2017)
creating filesystem with 101292 1k blocks and 25376 inodes
Filesystem UUID: 652bcf77-fe47-416e-952c-bbOa76a78407
Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729 
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done 

#mount /dev/md0p1 /mnt

#lsblk -o NAME,UUID,MOUNTPOINT /dev/sdb /dev/sdd
NAME      UUID                                 MOUNTPOINT
sdb       b3d82551-0226-6687-8279-b6dd6ad00d98
└─md0
  └─md0p1 652bcf77-fe47-416e-952c-bbOa76a78407 /mnt
sdd       b3d82551-0226-6687-8279-b6dd6ad00d98
└─md0
  └─md0p1 652bcf77-fe47-416e-952c-bbOa76a78407 /mnt

到目前为止,一切都很好。这不仅可以正确地将成员设备识别为 raid 设备,而且有两个匹配的分区级别 UUID。事实上,这些作为同一容器设备 md0 的一部分并列出相同的安装点。它不会列出 sdd 或 sdb 上的任何普通分区容器。请注意,md0 设备本身没有 UUID。只有其成员才有 UUID,并且其 UUID 实际上相同。

#echo "UUID=652bcf77-fe47-416e-952c-bbOa76a78407 /mnt ext4 rw,relatime,data=ordered 0 2" >> /etc/fstab
umount /mnt
mount /mnt
cd /mnt
fallocate -l 50MiB data

mdstat -> [UU]

请注意,我们要求提供 raid 成员的文件系统 UUID,现在让我们尝试在不运行 mdadm 的情况下运行系统。

#cd
#umount /mnt
#mdadm --stop /dev/md0
mdadm: stopped /dev/md0
#lsblk /dev/sdb /dev/sdd
NAME MAJ:MIN RM  SIZE  RO TYPE MOUNTPOINT
sdb    8:16   0  100M  0 disk
sdd    8:48   0  100M  0 disk

现在系统认为这些是正确的原始磁盘,因为它们没有分区表,因此不是容器。但是,如果我们问它们是什么:

#blkid /dev/sdd
/dev/sdd: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"

它仍然是一个 linux_raid_member,如果我们尝试挂载它:

#mount /dev/sdd /mnt
mount /mnt: unknown filesystem type "linux raid member"

怎么样:

#mount /mnt
mount: /mnt can't find UUID=652bcf77-fe47-416e-952c-bbOa76a78407

这是有道理的,因为 sdd 不是容器,因此没有被探测的文件系统。但是如果我运行:

#mdadm --assemble --scan && mount /mnt
mdadm: /dev/md0 has been started with 2 drives.

如果我再次停止它并删除 mdadm.conf:

#umount /mnt && mdadm --stop /dev/md0
#modprobe -r raid1
#rm /etc/mdadm.conf
#modprobe raid1
#mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 2 drives.

双重注意,我对 md0 设备名称的配置不再生效,并且它会自动在 /dev/md/0 创建。现在让我们重新启动并看看 systemd/Linux 使用 fstab 做了什么。

#mdadm --stop /dev/md/0
mdadm: stopped /dev/md/0
#systemctl reboot


#dmesg | grep md0
[  14.550231] md/raidl:md0: active with 2 out of 2 mirrors
[  14.550261] md0: detected capacity change from 0 to 104792064
[  14.836905]  md0: p1
[  16.909057] EXT4-fs (md0p1): mounted filesystem with ordered data mode. Opts: data=ordered

#lsblk /dev/md0
NAME      MAJ:MIN RM SIZE RO TYPE  MOUNTPOINT
md0       9:0     0  100M 0  raidl 
└─md0p1 259:0     0 98.9M 0  md    /mnt

再次使用 raid=noautoDetect 内核参数,因为这也会模拟不会自动检测所有 raid 和所有超级块/元数据版本等的 Linux 版本。但它仍然会挂载 raid,因为我在 fstab 中要求它,并且它强制加载 mod raid1 。因此,让我们再次尝试使用 modprobe.blacklist=raid1 将其列入黑名单:

在此输入图像描述

好吧,发生了什么事?:

在此输入图像描述

所以Linux知道它是一个raid类型的设备,即使它没有raid支持。当尝试安装它时,它会正确检测到它的 raid 设备,并且当使用 fstab 时,它找不到 UUID,尽管它位于文件系统超级块中。

然后再次! fstab 或 mdadm 中没有信息。

#mount /dev/sdd /mnt
mount: /mnt: unknown filesystem type "linux_raid_member".

我认为这的要点不仅在于 Linux 的探测是智能的。除了使用fdisk Warm等工具外,分区表区域中还填充了额外的信息。您必须非常努力才能使此错误成为其中一个成员磁盘的文件系统 UUID。

答案2

根据之前的答案,您可以在任何 RAID“级别”中使用 UUID,无需担心,方法是

  • 不使用 mdadm 元数据 v0.9 或 v1.0(而是使用 v1.1 或 1.2)
  • 使用与 MD 阵列关联的 UUID,而不是文件系统。当然,如果您将 FS 从软件 raid 移到不同的设备上,则需要重新配置,但您可能没有理由担心这一点。

在这种情况下,在 fstab 中配置 UUID 会出现问题

相关内容