コンテンツを含む既存のフォルダーを「マウント」するとどうなりますか？

現在/tmp、いくつかの一時ファイルが含まれています。の/dev/sdc1上にハードドライブ（）をマウントすると、ハードドライブ上の/tmpファイルを見ることができます。/tmpハードドライブがマウントされると、実際のコンテンツはどうなりますか？/tmpハードドライブがマウントされている間に、実際のコンテンツに対してr / w操作を実行することは可能ですか？

python@lanix / $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       286G   43G  229G  16% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            3.8G  4.0K  3.8G   1% /dev
tmpfs           766M  1.4M  765M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            3.8G   38M  3.8G   1% /run/shm
none            100M   24K  100M   1% /run/user
/dev/sdb1       7.5G  2.7G  4.9G  35% /mnt
/dev/sdc1       932G  242G  691G  26% /tmp

ハードドライブがマウントされると、/ tmpの実際の内容はどうなりますか？

ほとんど何もありません。これらはビューから隠されているだけであり、通常のファイルシステムトラバーサルでは到達できません。

ハードドライブがマウントされているときに、/ tmpの実際のコンテンツに対してr / w操作を実行できますか？

はい。「オリジナル」内でファイルハンドルを開いていたプロセス/tmpは、引き続きそれらを使用できます。他の場所にバインドマウントすることで、どこかで「再表示」することもでき/ます。

# mount -o bind / /somewhere/else
# ls /somewhere/else/tmp  

ここでは、何が起きているかをより良く（希望）感じるために実行できる小さな実験を示します。

注：これは完全に正しい試みではなく、実際に何が起こっているかを網羅的に説明するものでもありません。ただし、全体像を把握できるほど正確でなければなりません。

私meは自分のマシンで呼び出されるユーザーを作成し、自宅にランダムなディレクトリを作成し、その中にファイルを作成しました。

me@home $ pwd
/home/me/tmp
me@home $ echo hello > some_file
me@home $ ls  
some_file
me@home $ cat some_file 
hello

この時点で、異常なことは何もありません-それは単なるファイルのある単なるディレクトリです。cwdそのテストディレクトリ内で、セッションをそのまま開いたままにします。

ルートとして、小さなファイルシステムを作成し、それをマウントし/home/me/tmpます。

root@home # dd if=/dev/zero of=./fs bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00467318 s, 2.2 GB/s

root@home # mkfs -t ext2 ./fs 
mke2fs 1.42.12 (29-Aug-2014)
[... snip ...]
Writing superblocks and filesystem accounting information: done

root@home # mount ./fs /home/me/tmp

次に、新しいターミナルをとして開き、me辺りを見回します。

me@home #2 $ cd tmp
me@home #2 $ ls
lost+found
me@home #2 $ cat some_file
cat: some_file: No such file or directory
me@home #2 $ echo bye bye > some_file
-su: some_file: Permission denied

したがって、作成したファイルは明らかに存在しません。lost+foundディレクトリがextファイルシステムのルートを示しています。そして、書き込み許可を失ったため、明らかに元のディレクトリではありません。

最初のmeセッションに戻って、世界の見え方を見てみましょう。

me@home $ echo something else > other_file

書き込みは問題ありません。

me@home $ cat some_file other_file 
hello
something else

元のファイルはまだ存在し、新しいファイルは問題なく作成されます。

え？どうしたの？

最初のセッションは、別のファイルシステムをマウントするルートによってオーバーレイされる前にディレクトリに入りました。このマウントアクションは、元のファイルシステムにはまったく影響しません。シェルプロセスには、元のファイルシステムのディレクトリに対する完全に有効なハンドルがあり、引き続き対話することができます。一種の周りに走っているの下にカーペットのマウントポイント。

2番目のセッションは、マウントが置かれた後にディレクトリに入りました。したがって、新しい空のファイルシステムが表示されます。そして、システム管理者が許可を破棄したため、要求されたスペースを使用できません...それを修正しましょう。

root@home # chown me:users /home/me/tmp

me@home #2 $ echo bye bye > some_file
me@home #2 $ ls 
lost+found  some_file
me@home #2 $ cat some_file 
bye bye

セッション1はラグの下から脱出できますか？（カビが生えています。）

承知しました！セッション1がマウントからファイルシステムツリーを上に移動すると、内部へのハンドルが失われ、他の全員と同様にマウントを追跡します。

me@home $ cd
me@home $ pwd
/home/me
me@home $ cd tmp
me@home $ cat some_file other_file
bye bye
cat: other_file: No such file or directory

セッション＃2と同じビューで、通常の状態に戻りました。

しかし、ファイルが消えていないことをどうやって知るのですか？もう誰も見ていません！

これは、バインドマウントが便利になる瞬間の1つです。すでにマウントされているファイルシステムを別の場所にマウントできます。

me@home $ mkdir ~/bind

root@home # mount -o bind /home/me /home/me/bind

（はい、ファイルシステムを「内部」でバインドマウントできます。クールなトリックですよね？）

me@home $ ls bind/tmp
other_file  some_file
me@home $ cat bind/tmp/*
something else
hello

彼らは実際にそこにいて、行動の準備ができています。単に、元の場所でそれらが見えない/到達できないということです。マウントは、通常のディレクトリトラバーサルからそれらを隠します。

これをいじってみることをお勧めします。演奏されている「トリック」を理解すれば、本当に複雑ではありません。そして、Got It™を取得したら、ユニオンファイルシステムを調べて、さらにカーペットを引っ張ってください。

ただし、1つ注意してください。ブートプロセスが完了したら、/tmpまたは/var（またはコアOSディレクトリのいずれか）をマウントすることは実際には良い考えではありません。多くのアプリケーションはこれらのディレクトリに状態を残し、それらの周りでマウントゲームをプレイすると、深刻な混乱を招く可能性があります。