web-dev-qa-db-ja.com

シンボリックリンクの代わりにmount --bindを使用することの欠点はありますか？

シンボリックリンクは、ls、mv、cpなどの関数がそれらを操作できる方法に制限があります。これは、シェルが開始したcdなどのコマンドとは異なり、これらの関数にはユーザーが論理パスに関してディレクトリにアクセスした方法に関する情報（関連する post を参照）。マウントされたディレクトリはリンクではなく2つの独立した物理パスを持つため、mount --bindオプションを使用すると、これを回避でき、sambaや他のファイルサーバーとの機能と互換性が向上します。

mount --bindオプションを使用して、すべてのシンボリックリンクを参照に置き換えたいのですが、これはfstabに150以上のポイントをマウントすることを意味します。これまたは潜在的に私が考慮すべき他の欠点から生じる可能性のあるパフォーマンスの問題はありますか？

mountsymlink
59
mrtrujiyo

mount --bindを使用すると、ディレクトリツリーはディレクトリ階層の2つ（またはそれ以上）の場所に存在します。これは多くの問題を引き起こす可能性があります。バックアップおよびその他のファイルのコピーでは、すべてのコピーが選択されます。ファイルシステムをコピーすることを指定するのは難しくなります。バインドマウントされたファイルを2回コピーすることになります。 find、grep -r、locateなどで検索すると、すべてのコピーがトラバースされます。

バインドマウントでは、「機能と互換性の向上」は得られません。それらは他のディレクトリと同じように見えますが、ほとんどの場合、これは望ましい動作ではありません。たとえば、Sambaはデフォルトでシンボリックリンクをディレクトリとして公開します。バインドマウントを使用しても得られるものはありません。一方、バインドマウントは、NFSを介してディレクトリ階層を公開するのに役立ちます。

バインドマウントでパフォーマンスの問題は発生しません。あなたが持っているのは、管理の頭痛です。バインドマウントには用途があります。たとえば、chrootからディレクトリツリーにアクセスできるようにしたり、マウントポイントによって隠されたディレクトリを公開したりします（これは通常、ディレクトリ構造の再構築中の一時的な使用です）。必要がない場合は使用しないでください。

ルートのみがバインドマウントを操作できます。通常の方法では移動できません。彼らは自分の場所と祖先ディレクトリをロックします。

一般的に、コマンドにシンボリックリンクを渡すと、コマンドはファイルを操作する場合はリンク自体に作用し、ファイルの内容を操作する場合はリンクのターゲットに作用します。これはディレクトリにも当てはまります。これは通常正しいことです。一部のコマンドには、シンボリックリンクを別の方法で処理するオプションがあります。たとえば、ls -L、cp -d、rsync -lなどです。何をしようとしても、バインドマウントが適切なツールであるよりも、シンボリックリンクが適切なツールである可能性がはるかに高くなります。

62
Gilles 'SO- stop being evil'

以前に @ Gillesが書いたもの に加えて、一部のユーティリティmightがバインドマウントされたディレクトリを別のファイルシステム。同じiノード番号が同じファイルを参照していると（プログラムが異なるファイルシステム上にある場合はそうではない）プログラムが想定できない場合、これはパフォーマンスまたは機能に影響を与える可能性があり、移動をリンクとして最適化することはできません。 target-then-unlink-sourceなど.

14
a CVn

また、常にサポートされているとは限らないサポート（たとえば、外部ディスク）に依存している場合、シンボリックリンクの代わりにバインドマウントを使用する必要があります。失敗するか削除されます。

たとえば、/ var/tmpをsdカードに保持したい場合は、バインドマウントを使用します。これは、カードが削除されても、一部のプログラムは/ var/tmpが有効なディレクトリであることを期待するためです。

6
TopperH

/var（および/homeと/usr/local）が存在するシステムでpacman（archlinux、 ここについての詳細 ）を使用して一部のパッケージをインストールする問題を回避するためにバインドマウントを試みましたsymlinks（ファイルシステム全体：SSDからSATA）。

最初は見栄えは良かったが、Gillesが指摘したように、Prune_BIND_MOUNTS = "yes"の/etc/updatedb.conf行にもかかわらず、locateは常に1つのファイルに対して複数の結果を返しました。

$ locate \*/findutils-4.4.2 | xargs ls -ldiog
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /SHARED/LOCALS/Manjaro/src/findutils-4.4.2
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /usr/local/src/findutils-4.4.2

さらに少し掘り下げてみると、より複雑なバインドマウントが正しく削除される可能性があることがわかりました。

$ Sudo mount --bind /SHARED/LOCALS/common/ /usr/local/common
$ findmnt | fgrep -n sdb
34:├─/SHARED/LOCALS                  /dev/sdb5           ext4           rw,relatime,data=ordered
35:│ └─/SHARED/LOCALS/Manjaro/common /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
36:├─/usr/local                      /dev/sdb5[/Manjaro] ext4            rw,relatime,data=ordered
37:│ └─/usr/local/common             /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
38:├─/SHARED/HOMES                   /dev/sdb4           ext4            rw,relatime,data=ordered
39:├─/home                           /dev/sdb4[/Manjaro] ext4            rw,relatime,data=ordered
40:├─/SHARED/VARS                    /dev/sdb3           ext4            rw,relatime,data=ordered
41:├─/var                            /dev/sdb3[/Manjaro] ext4            rw,relatime,data=ordered
42:└─/opt                            /dev/sdb5[/opt]     ext4            rw,relatime,data=ordered

$ Sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
Prune_bind_mounts\000
Rebuilding bind_mount_paths:
Matching bind_mount_paths:
Skipping `/SHARED/LOCALS/Manjaro/common': bind mount
Skipping `/usr/local/common': bind mount

$ locate \*/mmedia
/SHARED/LOCALS/common/mmedia

Prune_BIND_MOUNTオプションがなければ、3つの結果が得られます。

$ Sudo sed -i '1 s/yes/no/' /etc/updatedb.conf 
$ Sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
Prune_bind_mounts\000
$ locate \*/mmedia
/SHARED/LOCALS/Manjaro/common/mmedia
/SHARED/LOCALS/common/mmedia
/usr/local/common/mmedia
$ Sudo sed -i '1 s/no/yes/' /etc/updatedb.conf

バインドマウントに関する別の問題：

もちろん、手動でバインドマウント（マウントポイントまたはターゲット）を/etc/updatedb.confのPRUNEPATHSに追加できます。

また、mountpointおよびさまざまなstatコマンドまたは関数をツールで使用して、ファイルシステムのトラバーサルを改善することができます ここで提案されています

1
RockyRoad

ファイルバインドマウントに関しては、シンボリックリンクよりもハードリンクに近い動作をします。これは、たとえば次のような微妙な結果をもたらす可能性があります。

# echo 1 > 1.txt
# touch 2.txt
# mount --bind 1.txt 2.txt
# cat 2.txt
1
# echo 1a > 1.txt
# cat 2.txt
1a

これまでのところ良好ですが、実際にファイルを変更するプログラム（エディター、適切に記述されたスクリプトなど）の数を検討してください。

# echo 1new > 1new.txt
# mv 1new.txt 1.txt
# cat 1.txt
1new
# cat 2.txt
1a

2.txtが1.txtへのシンボリックリンクだった場合、最後のコマンドは1newを出力します。これはおそらく予想されることです。

これはいくつかの微妙な問題を引き起こす可能性があります：systemdで BindReadOnlyPaths= を使用して、特定のサービスがシステムの他の部分とは異なるresolv.confファイルを使用するようにしましたが、 resolvconf はサービスの背後にあるソースファイルをreplaceするため、奇妙で不安定な方法で診断するのは難しい。

0
Etienne Dechamps