ln -s vs mount --bind
_ln -s_と_mount --bind_の使用に実際的な違いはありますか？
デーモン設定を変更せずに、いくつかのフォルダーを別のパーティションに移動し、どのようなアプローチをとるべきか迷っています。
最小限のセットアップが必要なため（_ln -s_の変更は不要）、私は_/etc/fstab_を好みますが、おそらくそれが一般的ではない理由があるのでしょうか？
もちろん。 ln -sを実行すると、特定のファイルシステムオブジェクトを指す inode であるシンボリックリンクが作成されます。これが、シンボリックリンクがファイルシステムをトラバースでき、ハードリンクがトラバースできない理由です。ハードリンクにはありません自分のiノード。
--bindを使用してファイルシステムをマウントする場合、デバイスまたはファイルシステム用に2番目のマウントポイントを作成します。
シンボリックリンクをリダイレクトとして想定する場合は、--bindマウントされたファイルシステムを、データへの別のゲートウェイを作成するものとして想定します。
シンボリックリンクとバインドマウントはまったく別の球技です。
--bindマウントは私にはもう少し堅牢に見え、シンボリックリンクを使用するよりも少し高速です。一方、パフォーマンスへの影響は小さいので（存在する場合）、symlinkを使用しても重大な欠点はありません。
編集：私はこれについて考えていました、そしてパフォーマンスヒットは最初に思ったよりも少し大きいかもしれません。多数の異なるファイルを読み取るアプリケーションがある場合、開かれるすべての新しいファイルには追加の読み取りが必要になります。いくつかの調査 here は私の仮定が正しいことを示唆しているため、IO重いアプリケーションを実行している場合は、--bindオプションを検討してシンボリックリンクの上にマウントすることを検討してください。解決。
一般的ではない理由は、おそらくシンボリックリンクがlsに表示されるという事実ですが、バインドマウントは/ proc/mountsまたは/ etc/mtab（マウントの内容）を見たときにのみ表示されますコマンドを実行します（パラメーターなしで実行した場合）。それ以外は問題ないと思います。でも、あれば興味があります。
追加：ln -sのもう1つの問題は、一部のアプリケーションでは、パスが逆参照されたときに、アプリケーションがパスすると、 "特定のアイテムが特定の場所にあることを期待しています。
ln -sとバインドマウントの大きな違いの1つは、バインドマウントを使用して読み取り専用ファイルシステムを「変更」できることです。たとえば、CDが/mnt/applicationにマウントされていて、/mnt/application/badconfigfile.confを正しいバージョンに置き換えたい場合は、次のようにします。
mount -o bind /path/to/correct/file.conf /mnt/application/badconfigfile.conf
ターゲットファイルシステムを変更できないため、シンボリックリンクを使用して同じ変更に影響を与えることはできません。
これは、NFS（またはある種のクラスターファイルシステム）を介して共通のソフトウェアスイートを配布し、1つのシステムでホスト固有の変更を行いたい場合にも使用できます。ターゲットシステムでバインドマウントを使用するだけで、必要に応じてファイルまたはディレクトリをオーバーライドできます。
私にとって、ln -sとmount --bindの実際的な違い＃1：
vsftpdでは、シンボリックリンクを介してディレクトリを参照することはできませんが、マウントされている場合は許可されます。
使用しているデーモンはわかりませんが、同様に動作する可能性があります。
それ自体がバインディングであるマウントへのバインディングの結果として、後でリバウンドされると、すべてが物理的に接続されたままであると想定して、元のバインディングは変更されないままであることに気付くかもしれません。
つまり、AをBにバインドし、BをCにバインドし、次にDをBにバインドした場合、Cは引き続きAにバインドされます。 CをBに追従させたい場合は、同じターゲット、つまりmount -o remount B Cを使用して再マウントするか、代わりに--rbindを使用します。 --rebindオプションはありません。