☰

为什么 `mount /dev/dm-8` 而是挂载 `/dev/dm-39` ？

tag-icon • tag-icon mount lvm btrfs uuid device-mapper
为什么 `mount /dev/dm-8` 而是挂载 `/dev/dm-39` ？

在带有 Linux 内核系统的 Debian 10 GNU 上，以下行没有像预期的那样挂载/dev/dm-8，但是（恕我直言，这是错误的）/dev/dm-37：

mount /dev/dm-8 /mnt

我现在真的很困惑，原因和/或如何进一步调查这个问题，我假设位于与 Linux 内核中块设备上的文件系统关联的 UUID 内。

背景信息和自己的研究:

  1. 基本信息：

    root@ada:/# 哪个挂载
/usr/bin/挂载
root@ada:/# 文件 /usr/bin/mount
/usr/bin/mount：setuid ELF 64 位 LSB 共享对象，x86-64，版本 1 (SYSV)，动态链接，解释器 /lib64/ld-linux-x86-64.so.2，用于 GNd
root@ada:/# uname -a
Linux ada 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux

  2. 使用逻辑卷管理器。唯一的卷组名为vg。

  3. 链接到块设备的两个卷包含一个btrfs，并且由于它们是由快照生成的，所以它们共享相同的fsid(UUID)。两个逻辑卷均设置为活动状态。

  4. 块设备/dev/dm-8并/dev/dm-37连接到这些逻辑卷：

    • /dev/dm-8->/dev/vg/vm_docu
    • /dev/dm-37->/dev/vg/vm_mail
root@ada:/# 真实路径 /dev/vg/vm_docu ;文件-s /dev/dm-8 ;
/dev/dm-8
/dev/dm-8：BTRFS 文件系统扇区大小 4096，节点大小 16384，叶大小 16384，UUID=d8709bb6-8278-431a-95dd-211ceaf35c3d，951652352/214748364800 bys
root@ada:/# 真实路径 /dev/vg/vm_mail ;文件-s /dev/dm-37 ;
/dev/dm-37
/dev/dm-37：BTRFS 文件系统扇区大小 4096，节点大小 16384，叶大小 16384，UUID=d8709bb6-8278-431a-95dd-211ceaf35c3d，1599131648/21474836480 bys
  1. 通过查看/usr/bin/mountwithstrace我可以看到发出了这个 mount(8) 系统调用：
挂载（“/dev/mapper/vg-vm_mail”，“/mnt”，“btrfs”，0，NULL）= 0

这表明，/dev/dm-8虽然没有从字面上转发到系统调用，/usr/bin/mount但也没有被误解，因为

 
root@ada:/# 真实路径 /dev/mapper/vg-vm_mail
/dev/dm-8

在涉及的工具/软件的嫌疑人列表中UUID，我包括：

  • 乌德夫
  • Linux 内核 - btrfs 代码
  • Linux内核-设备映射器
  • linux 内核 - lvm（如果内部还没有设备映射器）
  • 系统

答案1

BTRFS 文件系统绝不能有重复的 UUID。

真的，就是这么简单。Btrfs 使用文件系统 UUID 来识别哪些设备属于同一文件系统。这样您就可以拥有由/dev/sda、和 组成的 FS，/dev/sdb但/dev/sdc在安装之前不需要任何特殊命令来“组装阵列”。您只需运行mount /dev/sda /somewhere，BTFRS 就会自动检测哪些设备共享相同的 UUID/dev/sda并正确组装文件系统。

例如，这就是为什么您绝不能使用 btrfs 设备的块级副本或 LVM 快照的原因。任何导致同一块设备（具有相同 UUID）的多个“克隆”的行为都必然会混淆内核并导致严重的伤害。

因此，无论您遇到重复文件系统 UUID 的情况如何，都很难从中恢复。从头开始重新创建受影响的文件系统并从备份恢复可能是最简单的方法。

相关内容