☰

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

tag-icon • tag-icon mount lvm btrfs
`mount` 错误：`系统调用失败：文件存在。`

当我尝试挂载 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

答案1

（我不确定为什么要使用-o loop挂载选项，因为 LVM 快照设备应该与原始磁盘设备一样好。）

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

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

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

  • drivers/block/loop.c，与循环设备管理相关
  • 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文件系统超级块中的字段。

答案2

在更改分区的 UUID 后，我已成功挂载出现此问题的 BTRFS 分区。

答案3

当设备已安装在其他地方时会发生错误。您需要先卸载。然后你可以创建一个新的坐骑。

答案4

我之所以出现这种情况，是因为 Docker 容器仍在尝试访问主机上的挂载点，而主机也挂载在容器中。这是一个已断开连接的外部 USB 驱动器，容器阻止其重新安装。在重新安装之前停止容器解决了这个问题。

相关内容