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

（我不確定您為什麼要使用-o loopmount 選項，因為 LVM 快照設備應該與原始設備一樣好。）

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

系統呼叫沒有記錄該錯誤結果mount(2)，因此需要閱讀一些原始碼。

elixir.bootlin.com 上的 Linux 核心交叉引用器可以列出核心程式碼中使用 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文件系統超級塊中的欄位。

引用自：https://unix.stackexchange.com/questions/537029