Was passiert mit dem tatsächlichen Inhalt von / tmp, wenn meine Festplatte gemountet ist?
So ziemlich gar nichts. Sie sind nur unsichtbar und nicht über das normale Dateisystem erreichbar.
Ist es möglich, Schreib- / Lesevorgänge für den tatsächlichen Inhalt von / tmp auszuführen, während die Festplatte aktiviert ist?
Ja. Prozesse, in denen Dateihandles in Ihrem "Original" geöffnet waren /tmp, können diese weiterhin verwenden. Sie können das "Wiedererscheinen" auch an einer /anderen Stelle vornehmen, indem Sie es an einer anderen Stelle binden .
# mount -o bind / /somewhere/else
# ls /somewhere/else/tmp
Hier ist ein kleines Experiment, das Sie durchführen können, um ein besseres (ich hoffe) Gefühl für das zu bekommen, was gerade passiert.
Hinweis: Dies ist kein Versuch, vollkommen korrekt zu sein oder eine erschöpfende Beschreibung dessen, was wirklich passiert. Sollte genau genug sein, um Ihnen das Gesamtbild zu vermitteln.
Ich habe einen Benutzer erstellt, der meauf meinem Computer aufgerufen wurde , und ein zufälliges Verzeichnis in seinem Heim mit einer Datei darin:
me@home $ pwd
/home/me/tmp
me@home $ echo hello > some_file
me@home $ ls
some_file
me@home $ cat some_file
hello
An dieser Stelle nichts Ungewöhnliches - es ist nur ein einfaches Verzeichnis mit einer einfachen Datei. Ich lasse diese Sitzung offen, so wie sie ist, mit ihrem cwdInneren in diesem Testverzeichnis.
Als root erstelle ich ein kleines Dateisystem und mounte es über /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
Ich öffne dann ein neues Terminal als me, und schaue mich um:
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
Diese von uns erstellte Datei ist also eindeutig nicht vorhanden. Das lost+foundVerzeichnis gibt das Stammverzeichnis eines ext-Dateisystems an. Und ich habe die Schreibberechtigung verloren, es ist also eindeutig nicht das ursprüngliche Verzeichnis.
Zurück zur ersten meSitzung, schauen wir uns an, wie es die Welt sieht:
me@home $ echo something else > other_file
Kein Problem beim Schreiben.
me@home $ cat some_file other_file
hello
something else
Die ursprüngliche Datei ist noch vorhanden, die neue Datei wurde ohne Probleme erstellt.
Huh? Was ist los?
Die erste Sitzung wurde in das Verzeichnis eingetragen, bevor sie durch das Einhängen eines anderen Dateisystems in das Stammverzeichnis überlagert wurde. Diese Mount-Aktion wirkt sich überhaupt nicht auf das ursprüngliche Dateisystem aus. Der Shell-Prozess verfügt über ein vollständig gültiges Handle für das Verzeichnis im ursprünglichen Dateisystem und kann mit diesem weiter interagieren. Es ist eine Art herumlaufen unter dem Teppich Mount Point.
Die zweite Sitzung wurde in das Verzeichnis eingetragen, nachdem der Mount erstellt wurde. So sieht es das neue, leere Dateisystem. Und der Systemadministrator hat die Berechtigungen blockiert, sodass er den angeforderten Speicherplatz nicht verwenden kann. Lassen Sie uns das beheben.
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
Kann die erste Sitzung unter dem Teppich fliehen? (Es wird muffig.)
Sicher! Wenn Sitzung 1 den Dateisystembaum aus dem Mount zurückzieht, verliert er diesen Handle nach innen und folgt dem Mount wie alle anderen.
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
Gleiche Ansicht wie in Sitzung 2, wir sind wieder normal.
Aber woher wissen Sie, dass die Dateien nicht verschwunden sind? Niemand schaut mehr!
Dies ist einer der Momente, in denen Bindungshalterungen praktisch werden. Mit ihnen können Sie ein bereits bereitgestelltes Dateisystem an einer anderen Stelle bereitstellen.
me@home $ mkdir ~/bind
root@home # mount -o bind /home/me /home/me/bind
(Ja, Sie können ein Dateisystem "in sich selbst" binden. Cooler Trick, oder?)
me@home $ ls bind/tmp
other_file some_file
me@home $ cat bind/tmp/*
something else
hello
Sie sind also tatsächlich da, bereit zum Handeln. Es ist einfach so, dass sie an ihrem ursprünglichen Ort nicht sichtbar / erreichbar sind, der Mount verbirgt sie vor normalen Verzeichnisdurchläufen.
Ich ermutige Sie, damit herumzuspielen, es ist wirklich nicht kompliziert, wenn Sie den "Streich" verstanden haben, der gespielt wird. Und wenn Sie es einmal geschafft haben, schauen Sie sich Union-Dateisysteme an, um noch mehr Teppich zu ziehen :-)
Ein Hinweis: Das Mounten über /tmpoder /var(oder über eines der Hauptverzeichnisse des Betriebssystems) ist wirklich keine gute Idee, wenn der Startvorgang abgeschlossen ist. Viele Anwendungen lassen den Status in diesen Verzeichnissen und können ernsthaft verwirrt sein, wenn Sie Mount-Spiele in ihrer Umgebung spielen.