今/tmp、その中に一時ファイルがあります。/dev/sdc1その上にハードドライブ（）をマウントすると、ハードドライブの/tmpファイルを見ることができます。/tmpハードドライブを取り付けると、実際のハードドライブの内容はどうなりますか？/tmpハードディスクを装着した状態で実際の内容を読み書きできますか？
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
答え1
ハードドライブがマウントされると、/ tmpの実際の内容はどうなりますか？
ほとんど何も。これは単にビューから隠されており、一般的なファイルシステムナビゲーションではアクセスできません。
ハードディスクをマウントすると、/tmpの実際の内容を読み書きできますか？
はい。 「ソース」内でファイルハンドルを開いたプロセスは、/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と同じビューで、もう一度正常に戻ります。
しかし、ファイルが消えていないかどうかはどうすればわかりますか？もう誰もそれを探していません！
バインド装着が便利になる瞬間の一つです。すでにマウントされているファイルシステムを他の場所にマウントできます。
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
それで彼らは実際に措置を取る準備ができています。元の場所では表示/アクセスできず、インストール中の一般的なディレクトリナビゲーションでは非表示になります。
一度試してみることをお勧めします。プレイしている「トリック」を理解したら、実際には複雑ではありません。慣れたら、より多くのラグプーリングのためにUnion File Systemを見てください :-)
しかし、注意すべき点は、ブートプロセスが完了したら/tmp（またはコアオペレーティングシステムディレクトリ）/varにインストールすることは本当に良い考えではないということです。多くのアプリケーションがこれらのディレクトリの状態を維持しているため、そのアプリケーションを中心にインストールゲームをプレイすると深刻な混乱を招く可能性があります。