Was bedeutet die 4. Spalte (Root) in /proc/.../mountinfo?

Was bedeutet die 4. Spalte (Root) in /proc/.../mountinfo?

Im procHandbuch wird die vierte Spalte mountinfoals „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/bzeigt die Wurzelspalte /test_dir/a, warum wird der /runTeil 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.comauf /var/www/html/example.com. Jetzt erstellen Sie eine Datei /var/www/html/example.com/test.html. Wenn Sie sie https://example.com/test.htmlin Ihrem Browser öffnen, erhalten Sie den Inhalt der erstellten Datei. Wenn Sie sie /var/www/htmlals Root festlegen, müssen Sie sie öffnenhttps://example.com/example.com/test.html
  • Wenn Sie chrootin das Verzeichnis gehen /home/test/testSystem/. Die Wurzel dieser Umgebung wäre . Wenn Sie in der chroot-Umgebung /home/test/testSystemeinen ausführen, erhalten Sie den Inhalt vonlsls //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, /mnterhalten 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 mountinfosä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/test2ist /var/test1. Die Mountquelle (was Sie gemountet haben) ist/dev/sda

Zurück zum USB-Beispiel: Wenn Sie den Inhalt von jetzt /mnt/dir1auf etwas anderes mounten, erhalten Sie die Mount-Root /dir1und die Mount-Quelle wäre /dev/sdb(der USB). Der /mntTeil wird hier gelöscht.

„Warum den /run-Teil verstecken?“

Kurz gesagt: /runwird gelöscht, weil es eine tmpfs-Partition ist. Warum werden diese Teile entfernt?

Im USB-Beispiel haben wir dir1von /dev/sdbauf 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/dir1wir den tatsächlichen Speicherort auf dem USB-Stick nicht kennen: Es könnte sein /dir1, /usb/dir1oder vielleicht/mnt/usb/dir1

verwandte Informationen