Im proc
Handbuch wird die vierte Spalte mountinfo
als „root“ bezeichnet und als „der Pfadname des Verzeichnisses im Dateisystem, das die Wurzel dieses Mounts bildet“ beschrieben. Aber wie ist das zu verstehen?
Ich dachte, die Grundelemente eines Mounts seien der Quell- und der Zielpfad. Da sich die „Mount-Quelle“ in der 10. Spalte und das Ziel in der 5. Spalte befindet, wofür wird dann die Wurzel verwendet?
Für die meisten Mount-Informationen ist die Wurzel einfach /
, was bedeutungslos zu sein scheint. Ich finde nur, dass die Bind-Mounts eine andere Wurzel haben als /
, also ist es nur bei Bind-Mounts nützlich? Und warum wird im Bind-Fall nicht der absolute Pfad in der Wurzel angezeigt? Wenn beispielsweise an gebunden wird /run/test_dir/a
, /run/test_dir/b
zeigt die Wurzelspalte /test_dir/a
, warum wird der /run
Teil ausgeblendet?
Antwort1
Es ist schwer, es mit Sprachelementen zu erklären (zumindest mit meinen Englischkenntnissen) - also habe ich beschlossen, eine beispielbasierte Antwort zu geben:
Das Stammverzeichnis wird oft alshöchsteoderam höchstenVerzeichnis. Dies ist nur teilweise wahr. Dieses Verzeichniswird angenommenals diehöchsteVerzeichnis. Sie könnten es mit „von diesem Verzeichnis aus werde ich beginnen – ich gehe davon aus, dass dies das oberste Verzeichnis ist und darüber nichts steht“ beschreiben.
Einige Beispiele zur Verdeutlichung der Bedeutung von „Wurzel“:
- Stellen Sie sich vor, Sie betreiben einen Webserver und setzen den Stamm einer Domäne
example.com
auf/var/www/html/example.com
. Jetzt erstellen Sie eine Datei/var/www/html/example.com/test.html
. Wenn Sie siehttps://example.com/test.html
in Ihrem Browser öffnen, erhalten Sie den Inhalt der erstellten Datei. Wenn Sie sie/var/www/html
als Root festlegen, müssen Sie sie öffnenhttps://example.com/example.com/test.html
- Wenn Sie
chroot
in das Verzeichnis gehen/home/test/testSystem/
. Die Wurzel dieser Umgebung wäre . Wenn Sie in der chroot-Umgebung/home/test/testSystem
einen ausführen, erhalten Sie den Inhalt vonls
ls /
/home/test/testSystem/
Einhängepunkt mit Root/
Ein USB-Stick enthält beispielsweise:
/
├── dir1
│ ├── subfile1
│ └── subfile2
├── file1
├── file2
└── file3
Wenn Sie diesen USB-Stick mounten, /mnt
erhalten Sie die erwartete normale Ausgabe, da Sie das /
Verzeichnis des USB-Sticks als Root verwenden:
531 137 0:52 / /mnt rw,nosuid,nodev shared:75 - /dev/sdb [...]
In den meisten Fällen wäre die Wurzel der Einhängepunkte also tatsächlich /
.
Einhängepunkt mit anderer Wurzel als/
Sie können dies selbst versuchen: Binden Sie zwei Verzeichnisse in Ihrem Dateisystem zusammen mit
$ mount --bind /var/test1 /var/test2
Die Ausgabe mountinfo
sähe etwa so aus:
564 29 0:26 /var/test1 /var/test2 rw,relatime shared:1 - ext4 /dev/sda rw [...]
Die Wurzel des Mountpoints unter /var/test2
ist /var/test1
. Die Mountquelle (was Sie gemountet haben) ist/dev/sda
Zurück zum USB-Beispiel: Wenn Sie den Inhalt von jetzt /mnt/dir1
auf etwas anderes mounten, erhalten Sie die Mount-Root /dir1
und die Mount-Quelle wäre /dev/sdb
(der USB). Der /mnt
Teil wird hier gelöscht.
„Warum den /run-Teil verstecken?“
Kurz gesagt: /run
wird gelöscht, weil es eine tmpfs-Partition ist. Warum werden diese Teile entfernt?
Im USB-Beispiel haben wir dir1
von /dev/sdb
auf gemountet /home/test/usbmnt/
. Die Ausgabe wäre:
564 29 0:26 /dir1 /home/test/usbmnt/ rw,relatime shared:1 - ext4 /dev/sdb rw [...]
Sie sehen, dass wir den Inhalt von /dir1 (vom USB und NICHT von Ihrer Festplatte) in ein Verzeichnis namens usbmnt gemountet haben. Vielleicht ist es hilfreich, es als zu lesen /dev/sdb/dir1
.
Wenn das Root-Recht angegeben wird, da /mnt/usb/dir1
wir den tatsächlichen Speicherort auf dem USB-Stick nicht kennen: Es könnte sein /dir1
, /usb/dir1
oder vielleicht/mnt/usb/dir1