`mount`エラー: `システムコールに失敗しました:ファイルが存在します。 `

`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スナップショットデバイスをマウントする方法は?

最後に確認したのは2018年10月でしたが、mountコマンドは「常に機能しました」。存在するこれは3年前に受け取った質問です。。しかし、エラーメッセージは少し異なり、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スナップショットデバイスはRAWディスクデバイスと同じくらい優れていると仮定されているため、マウントオプションを使用したい理由がわかりません。)

「ファイルが存在します」は、値が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エラーが発生します。しかし、mountコマンドで競合条件を作成することがなければ、ここでは問題になりません。EEXISTmount -o loop=/dev/loop3 .../dev/loop3

実際には、エラーコードをエラーメッセージに変換する特定の機能がfs/btrfs/super.cあります。にbtrfs翻訳されます。EEXISTObject 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ドライブで、コンテナのため再マウントできません。再インストールする前にコンテナを停止すると問題が解決しました。

関連情報