`mount` 错误：`系统调用失败：文件存在。`

Question

当我尝试挂载 lvm 快照设备时，出现错误：

$ sudo mount -o loop /dev/mapper/matrix-snap--of--core /home/me/mountpoint
mount: /home/me/mountpoint: mount(2) system call failed: File exists.

• 什么是“文件存在”。试图告诉我的错误？
• 如何挂载lvm快照设备？

mount 命令“以前一直有效”，尽管我上次检查是在 2018 年 10 月。在这个三年前的问题中遇到了类似的错误。但是，错误消息略有不同，现在是 2019 年……

---

这是我的输出lsblk。

NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 465.8G  0 disk  
??sda1                          8:1    0 465.8G  0 part  
  ??core                      254:0    0 465.8G  0 crypt 
    ??matrix-swapvolume       254:1    0     4G  0 lvm   [SWAP]
    ??matrix-core-real        254:3    0 461.8G  0 lvm   
      ??matrix-core           254:2    0 461.8G  0 lvm   /
      ??matrix-snap--of--core 254:5    0 461.8G  0 lvm   
sdb                             8:16   1  59.5G  0 disk  
??matrix-snap--of--core-cow   254:4    0  59.5G  0 lvm   
  ??matrix-snap--of--core     254:5    0 461.8G  0 lvm   

我运行 Parabola Linux，我的系统是最新的。逻辑卷/dev/matrix/core使用btrfs，我怀疑这与错误有关。这是我的输出uname -rvs。

Linux 5.2.5-gnu-1 #1 SMP PREEMPT Sun Aug 4 02:02:20 UTC 2019

Answer 1

（我不知道你为什么使用-o loop挂载选项，因为 LVM 快照设备应该和它的原始磁盘设备一样好。）

“文件存在”是errno值 17的标准英文文本，或者EEXIST如#include <errno.h>.

mount(2)系统调用没有记录该错误结果，因此需要阅读一些源代码。

elixir.bootlin.com 上的 Linux 内核交叉引用可以列出内核代码中使用 EEXIST 的所有位置。由于您正在尝试循环挂载btrfs文件系统，因此可能相关的地方是：

• drivers/block/loop.c, 与loop设备管理有关
• fs/btrfs/super.c，这将在挂载btrfs文件系统时使用。

在 中drivers/block/loop.c，EEXIST如果您尝试分配已在使用（例如mount -o loop=/dev/loop3 ...，/dev/loop3已被占用）的特定循环设备，则会生成错误。但这不应该是这里的问题，除非您的 mount 命令产生了竞争条件。

在fs/btrfs/super.c实际上有一个btrfs用于翻译错误代码转换成错误消息特异性功能。它翻译EEXIST成Object already exists.

您正在尝试挂载看起来像是btrfs已挂载的文件系统的克隆的东西，因此它实际上是有道理的：从历史上看，这曾经btrfs令人困惑，但似乎在某些时候（明智地）添加了一些保护。

由于这似乎是LVM 级别的快照，而不是使用btrfs的内置快照功能制作的快照，如果您希望在挂载原始文件系统的同时挂载它，则必须将快照视为克隆的文件系统：只有LVM 会“知道”它是快照，而不是实际的 1:1 克隆。因此，如果您需要将快照/克隆文件系统安装在与原始文件系统相同的系统上，则需要更改它的元数据 UUID。

警告：我对 没有太多经验btrfs，因此以下内容可能有误或不完整。

由于您的内核比 5.0 新，您可以选择使用btrfstune -m /dev/mapper/matrix-snap--of--core来进行更改。否则，您将不得不使用btrfstune -u /dev/mapper/matrix-snap--of--core哪个会更慢，因为它需要更新所有文件系统元数据，而不仅仅是metadata_uuid文件系统超级块中的字段。