Wie kann findmnt Bindungs-Mounts auflisten?

Viele Leute sagen immer wieder, dass Linux keine Informationen über Bindungs-Mounts speichert, daher gibt es keine Möglichkeit, eine Liste von ihnen und ihren Quellen zu erhalten. Hier sind einige Beispiele:

aus einem der Kommentare hier :

IIRC Diese Informationen werden nirgendwo aufbewahrt: Nachdem mount --binddie beiden Kopien gleichwertig sind, gibt es keine, die „origineller“ ist als die andere. Schließlich könnte es kein Original geben, wenn Sie bereits abgemeldet wären /mnt.
von einer Antwort auf dieser Seite :

Die einzige Möglichkeit, sich daran zu erinnern, welche Mounts Bindungs-Mounts waren, ist das Protokoll der verbleibenden Mount-Befehle /etc/mtab. Eine Bind-Mount-Operation wird durch die Bind-Mount-Option angezeigt (wodurch der Dateisystemtyp ignoriert wird). Mount hat jedoch keine Option, nur Dateisysteme aufzulisten, die mit einem bestimmten Satz von Optionen gemountet wurden.
aus einem Debian-Fehlerbericht :

Dies ist beabsichtigt. Beide Mount-Punkte sind in jeder Hinsicht vollständig gleich, sodass der Kernel keine Flags behält, um sie zu unterscheiden.

Das obige ist jedoch Unsinn. Das Tool findmntkann die Quellpfade von Bindungs-Mounts auflisten (in Form von device[source-path]; ich versuche auch, es dazu zu bringen, nur den Quellpfad und nicht das Gerät aufzulisten). Wenn der Linux-Kernel einen Bind-Mount verwalten soll, müssen diese Informationen irgendwo gespeichert werden , andernfalls konnte er nicht wissen, dass sie /homegebunden sind /users. Wo sind diese Daten? Wird es in einem dunklen Bereich im RAM gespeichert? Hat findmntBlick in /procirgendwo?

linux mount bind-mount

— Melab
quelle

Welche Version von findmntläuft und welche Optionen geben Sie ihr? Meins druckt es nicht so aus und schaut sich den Quellcode an, den es zu verwenden scheint , _PATH_PROC_MOUNTINFOder aussieht, /proc/self/mountinfoder diese Informationen auch nicht enthält.

— Bratchley

OK, ich denke, vor /proc/self/mountinforelativ kurzer Zeit wurde umstrukturiert. Ich war auf meinem RHEL6-Computer, auf dem zuvor keine Pfadinformationen vorhanden waren, aber auf meinem RHEL7-Computer und wie in Ihrem Link erwähnt, auch auf Wheezy.

— Bratchley

Es ist kein Unsinn: Es stimmte mit älteren Kerneln überein, aber neuere Kernel verfolgen die Informationen.

— Gilles 'SO - hör auf böse zu sein'

@ Gilles Wie kann dann ein Bind-Mount bestehen bleiben, wenn die Information, dass ein Verzeichnis in einem anderen gemountet ist, nicht verfolgt wird?

— Melab

@Melab Tatsächlich ist es für ein Bind-Mount einfacher zu bestehen, wenn Sie nicht nachverfolgen, dass es sich um ein Bind-Mount handelt. Wenn /dev/Abei /Bund Sie gemountet sind mount --bind /B /C, erinnern sich ältere Kernel nur an /B → /dev/Aund /C → /dev/Asie erinnern sich an keine Beziehung zwischen /Bund /C. Das Abhängen /Bhat also natürlich keine Auswirkung auf /C. Neuere Kernel erinnern sich, dass dies /Cein Bind-Mount von war /B, aber auf eine Weise, die nicht verhindert, dass sie weiterarbeiten, /Cwenn sie nicht gemountet sind , /Bweiß ich nicht genau, wie.

— Gilles 'SO - hör auf böse zu sein'

Antworten:

Sie haben ein wenig falsch verstanden; die beiden Bereitstellungspunkte sind gleich in Bezug auf die Berechtigungen, Fahnen, etc , weil die Bindung effektiv Zugriff von einem Pfad zum anderen leitet. Aber sie sind immer noch verschieden .

Wenn Sie sich das ansehen, sehen /proc/self/mountinfoSie die Kernelansicht der Mount-Welt für diesen Prozess (Namespaces machen die Dinge komplizierter; es gibt nicht nur eine Ansicht der Mount-Tabelle).

man 5 procwird das Format dieser Datei erklären, aber Sie können die Baumhierarchie sehen und sehen, wo Bindungs-Mounts ihre "Eltern" haben. Dies ist die Datei, die findmntanalysiert wird.

— Stephen Harris
quelle

Linux speichert nicht die Informationen darüber, welches Mount ein Bind-Mount war . Es werden Informationen zu allen Mounts einschließlich Bind-Mounts gespeichert .

Es ist ziemlich ähnlich zu harten Links. Mounts verknüpfen mit Dateisystemen wie Dateinamen mit Inodes. Die einzigen Unterschiede bestehen darin, dass Mounts auch Mount-Flags haben und sich möglicherweise auf ein Unterverzeichnis des Zieldateisystems anstelle des Dateisystemstamms beziehen.

Wenn Sie einen festen Link erstellen, speichert das Dateisystem nicht, welcher Dateiname der ursprüngliche und welcher der feste Link war. Beide beziehen sich einfach auf dieselbe Inode. Wenn Sie die Verknüpfung der Originaldatei aufheben, ist die Situation nicht zu unterscheiden, wenn Sie die Datei direkt mit dem zweiten Dateinamen erstellt haben.

Zurück zum Binden von Mounts: Der Kernel verwaltet eine Tabelle, die das Dateisystem (gekennzeichnet durch ein Paar aus Major: Minor-Nummern), den Mountpoint, den Pfad relativ zum Dateisystemstamm und einige Flags enthält. Sie können auf diese Liste zugreifen, indem Sie auf schauen /proc/self/mountinfo. (Es wird komplizierter, wenn Namespaces beteiligt sind, wie @ stephen-harris erwähnt hat). findmntanalysiert diese Liste.

Wenn Ihre Wurzel /dev/sda1mit dem Dur: Moll ist 8:1und Sie ausführen mount --bind /a /b /proc/self/mountinfo, enthält es ähnliche Zeilen:

1 0 8:1 / / rw - ext4 /dev/sda1 rw,errors=remount-ro
2 1 8:1 /a /b rw - ext4 /dev/sda1 rw,errors=remount-ro

Wenn Ihr /homeist /dev/sda2mit der Haupt: minor 8:2und führen Sie mount --bind /home /userses wie folgt aussehen:

1 0 8:1 / / rw - ext4 /dev/sda1 rw,errors=remount-ro
2 1 8:2 / /home rw - ext4 /dev/sda2 rw
3 1 8:2 / /users rw - ext4 /dev/sda2 rw

Die relevanten Spalten für Ihre Frage sind die dritte, die vierte und die fünfte. Dies ist die Dateisystem-ID (für reale Dateisysteme ist sie dieselbe wie für das Gerät major: minor; für virtuelle Dateisysteme wie tmpfs ist es [0: counter ]), der Pfad relativ zum Dateisystemstamm, der an den Mountpoint gebunden ist (normalerweise / für normal) Mounts, kann alles für Bind-Mounts sein) und den Mountpoint.
Die Bedeutung der verbleibenden Spalten finden Sie in der Dokumentation zum Linux-Kernel .

findmntruft den Quellpfad relativ zum Dateisystemstamm "FSROOT" auf. Sie können es verwenden findmnt -o TARGET,FSROOT, um es zu bekommen. Wenn Sie den absoluten Quellpfad möchten, müssen Sie ihn wahrscheinlich /proc/self/mountinfoselbst analysieren und die Informationen zu den Bereitstellungen für dasselbe Dateisystem kombinieren.

Weitere Informationen finden Sie in meiner Antwort auf "Liste nur Bindungshalterungen" .

— cg909
quelle

Wenn /proc/self/mountinfoenthalten können Zeilen wie 2 1 8:1 /a /b rw - ext4 /dev/sda1 rw,errors=remount-ro, dann die meisten Linux sicherlich tut zu binden Halterungen einige Informationen halten.

— Melab

Schauen Sie sich mein zweites Beispiel an. Es speichert die Informationen, welches Dateisystem gemountet wurde und welcher Pfad relativ zum Dateisystemstamm gemountet wurde . Also für mount --bind /home/melab /mntdie resultierende Linie könnte wie eine der folgenden aussehen , je nachdem , welche /homeund /home/melabist ein Mount - Punkt: 3 1 8:1 /home/melab /mnt rw - ext4 /dev/sda1 rw, 3 1 8:2 /melab /mnt rw - ext4 /dev/sda2 rw,3 1 8:3 / /mnt rw - ext4 /dev/sda3 rw

— cg909

Es ist wahr, dass etwas anderes als /in der vierten Spalte häufig auf ein Bind-Mount hinweist. Es könnte sich aber auch um ein Btrfs-Subvolumen handeln.

— CG909

Soll /dev/sda3an montiert werden /home/melab?

— Melab

Ja. In meinem Beispiel habe ich /dev/sda1als /, /dev/sda2als /homeund /dev/sda3als/home/melab

— cg909