Warum geschieht das Einhängen über ein vorhandenes Verzeichnis?

Ein vorhandenes Verzeichnis wird als Einhängepunkt benötigt .

$ ls
$ sudo mount /dev/sdb2 ./datadisk
mount: mount point ./datadisk does not exist
$ mkdir datadisk
$ sudo mount /dev/sdb2 ./datadisk
$

Ich finde es verwirrend, da es vorhandene Inhalte des Verzeichnisses überlagert. Es gibt zwei mögliche Inhalte des Mount-Point-Verzeichnisses, die möglicherweise unerwartet gewechselt werden (für einen Benutzer, der das Mount nicht ausführt).

Warum passiert das nicht mountin einem neu erstellten Verzeichnis? Auf diese Weise zeigen grafische Betriebssysteme Wechselmedien an. Es wäre klar, ob das Verzeichnis gemountet (existiert) oder nicht gemountet (existiert nicht) ist. Ich bin mir ziemlich sicher, dass es einen guten Grund gibt, aber ich konnte es noch nicht entdecken.

Dies ist ein Fall eines Implementierungsdetails, das durchgesickert ist.

In einem UNIX-System besteht jedes Verzeichnis aus einer Liste von Namen, die Inode- Nummern zugeordnet sind. Eine Inode enthält Metadaten, die dem System mitteilen, ob es sich um eine Datei, ein Verzeichnis, ein spezielles Gerät, eine Named Pipe usw. handelt. Wenn es sich um eine Datei oder ein Verzeichnis handelt, teilt sie dem System auch mit, wo sich der Datei- oder Verzeichnisinhalt auf der Festplatte befindet. Die meisten Inodes sind Dateien oder Verzeichnisse. Die -iOption zum lsAuflisten von Inode-Nummern.

Beim Mounten eines Dateisystems wird ein Verzeichnis-Inode verwendet und in der In-Memory-Kopie des Kernels ein Flag gesetzt, das besagt: "Wenn Sie nach dem Inhalt dieses Verzeichnisses suchen, schauen Sie sich stattdessen dieses andere Dateisystem an" (siehe Folie 10 dieser Präsentation ). Dies ist relativ einfach, da ein einzelnes Datenelement geändert wird.

Warum wird kein Verzeichniseintrag erstellt, der auf den neuen Inode verweist? Sie können dies auf zwei Arten implementieren, die beide Nachteile haben. Eine besteht darin, ein neues Verzeichnis physisch in das Dateisystem zu schreiben - dies schlägt jedoch fehl, wenn das Dateisystem schreibgeschützt ist! Das andere ist, zu jedem Verzeichnislistenprozess eine Liste von "zusätzlichen" Dingen hinzuzufügen, die nicht wirklich vorhanden sind. Dies ist umständlich und kann bei jedem Dateivorgang zu einer geringen Leistungseinbuße führen.

Wenn Sie dynamisch erstellte Einhängepunkte wünschen, kann das automountSystem dies tun. Spezielle nicht-Disk - Dateisysteme können auch Verzeichnisse nach Belieben erstellen, zum Beispiel proc, sys, devfsund so weiter.

Bearbeiten: Siehe auch die Antwort auf Was passiert, wenn Sie einen vorhandenen Ordner mit Inhalten überladen?

Wenn die Erstellung eines neuen Verzeichnisses als Einhängepunkt mount(2) erforderlich ist, können Sie unter einem schreibgeschützten Dateisystem nichts einhängen. Das wäre dumm, also können wir das ausschließen.

Wenn mount optional ein neues Verzeichnis als Mountpoint erstellen würde, wäre das seltsam. Es ist nicht so, dass das Ein- und Aushängen ständig passiert. Daher wäre es keine wichtige Beschleunigung, zusätzliche Logik in den Kernel zu integrieren, um diese beiden Schritte mit einem einzigen Systemaufruf auszuführen. Überlassen Sie es einfach dem Benutzerraum, um einen mkdir(2)Systemaufruf zu tätigen , wenn dies gewünscht wird. Die Antwort von Dmitry weist darauf hin, dass mount(2)es nicht atomar wäre , wenn man beide Dinge tun würde. Und würden Sie an ein zusätzliches Argument wollen mount(2)mit Modus - Flags wie open(2)nimmt, für O_CREAT, O_EXCLusw. Es wäre einfach albern sein im Vergleich zu lassen User-Space tun es.

Oder haben Sie sich gefragt, mount(8)ob (das traditionelle Programm, das mount(2)Systemaufrufe ausführt) dies tun soll? Das wäre möglich, aber es gibt bereits ein perfektes mkdir(1)Werkzeug für den Job, und im Design von Unix dreht sich alles um gute kleine Werkzeuge, die kombiniert werden können. Wenn Sie ein Tool suchen, das beides kann, ist es einfach, ein Shell-Skript zu schreiben, um dieses Tool aus zwei einfacheren Tools zu erstellen. (Oder, wie muru bemerkte, udisksctltut dies bereits, so dass Sie es nicht schreiben müssen.) Außerdem mount(8)unterstützt Linuxs Standard von util-linux die mount -o x-mount.mkdir[=mode]Verwendung seiner x-Syntax für Optionen für den Benutzerbereich anstelle von Optionen, die an das Dateisystem übergeben werden sollen.

Nun die interessantere Frage: Warum muss es überhaupt ein Verzeichnis im übergeordneten Dateisystem geben?

Wie die Antwort von pjc50 zeigt (keine Beziehung, obwohl er meine Initialen hat!), Würde es dann eine zusätzliche Überprüfung erfordern, wenn Mount-Punkte in Verzeichnislisten angezeigt werden readdir().

Mount-Punkte als Verzeichnisse in dem Verzeichnis zu haben, das sie enthält (auf dem übergeordneten FS), ist ein netter Trick. readdir()muss nicht bemerken, dass es sich überhaupt um einen Einhängepunkt handelt. Dies geschieht nur, wenn der Einhängepunkt als Pfadkomponente verwendet wird. Die Pfadauflösung muss natürlich die Mount-Tabelle für jede Verzeichniskomponente eines Pfades überprüfen.

Das Mounten in ein vorhandenes Verzeichnis ruft mountpraktisch atomar auf: Zumindest aus Benutzersicht gelingt dies oder schlägt fehl. Wenn mountder Mountpunkt selbst erstellt werden müsste, hätte er zwei Fehlerquellen, sodass ein sauberes Rollback nicht garantiert werden kann. Stellen Sie sich folgendes Szenario vor:

1. mount erstellt den Mountpoint erfolgreich
2. mount versucht, ein neues Dateisystem in dieses Verzeichnis einzuhängen, schlägt jedoch fehl
3. mount versucht, den Mountpoint zu entfernen, schlägt jedoch fehl

Das System hat die Nebenwirkung eines fehlgeschlagenen mount.

Hier ist ein anderes:

1. umount Hängt ein Dateisystem erfolgreich ab
2. umount versucht, den Mountpoint zu entfernen, schlägt jedoch fehl

Nun sollte umountErfolg oder Misserfolg zurückkehren?

Ein weiterer Fall, der auftreten kann:

Beim Booten wird ein schreibgeschütztes Basisimage in das Stammverzeichnis geladen. Sie möchten es also überschreiben, wenn Sie eine echte Wurzel schlagen möchten. Sie können sich also vorstellen, dass mount syscall nur den roMountpoint zu vertauscht rw.

Stellen Sie sich vor, Sie haben ein Dateisystemproblem auf dem Root-Mountpoint und möchten versuchen, es zu reparieren. Mit Mount-Überlappung können Sie das Dateisystem aushängen und das fsckbereitgestellte Basis-Image zur Lösung verwenden.

Diese Funktion kann auch in Systemen nützlich sein, die eine hohe Sicherheit benötigen, um Änderungen zwischen einer roPartition und einer anderen rwnachzuverfolgen.

Das habe ich mich auch immer gefragt.

Ein einfacher Wrapper wie:

#!/bin/sh
eval "mkdir -p \"\$$#\"" 
/bin/mount "$@"  

Das Speichern als ausführbares Skript mit dem Namen mountin einem Verzeichnis, das /binIhren PATH überschreibt, sollte dies berücksichtigen, wenn es Sie zu sehr stört

(Bevor die eigentliche mountBinärdatei ausgeführt wird, wird ein Verzeichnis erstellt, das nach dem letzten Argument von to benannt ist mount, sofern ein solches Verzeichnis noch nicht vorhanden ist.)

Wenn Sie nicht möchten, dass fehlgeschlagene Aufrufe des mountWrappers Verzeichnisse erstellen, können Sie Folgendes tun:

#!/bin/sh
set -e
eval "lastArg=\"\$$#\""
test -d "$lastArg" || { mkdir "$lastArg"; madeDir=1; }
/bin/mount "$@"  ||  {  test -z "$madeDir" || rmdir "$lastArg"; }