Das Einhängen einer Bind-Quelle funktioniert nicht und das Gerät hat nicht genügend Speicherplatz

Question

Das Problem

/mnt/srcnimmt keinen Speicherplatz ein, aber Sie sollten es aushängen, um einige Tools, einschließlich Tools, die Backups durchführen, nicht zu verwirren. lsblkWählt beispielsweise die Anzeige des ersten passenden Mounts und zeigt /mnt/srcstattdessen /für an /dev/vda2, was nicht optimal ist.

Die meisten Linux-Systeme laufensystemdalso nehme ich an, dass dieses System läuftsystemd.

systemdremontiert / alsgeteiltmount anstelle des Standardwerts des Linux-Kernels vonPrivat. Die Kernel-Dokumentation zur Mount-Propagation finden Sie hier:Gemeinsam genutzte Teilbäume. Das bedeutet, dass wenn später zusätzliche Mounts hinzugefügt (oder entfernt und wieder hinzugefügt) werden, diese ebenfalls automatisch durch den Propagierungsmechanismus /gemountet werden , und/mnt/srcseit seinergeteilt(stattSklave) Wenn Sie versuchen, sie von zu trennen, /mnt/srcwerden sie auch von/, die entweder fehlschlagen (weil sie von Prozessen verwendet werden) oder bei Erfolg möglicherweise Schaden anrichten (sie verschwinden auch von ihrem ursprünglichen Einhängepunkt).

Was hätte getan werden sollen?

Führen Sie solche Bind-Mounts immer mit demPrivatPropagierungsoption. Wenn Sie dabei sind und es zu Sicherungszwecken verwenden, lassen Sie auch die Bind-Einbindung schreibgeschützt (neu) einbinden:

mount --bind --make-private -o ro / /mnt/src

Auf diese Weise wird keine weitere Interaktion mit anderenAnschlüssewird passieren und dies kann jederzeit mit einem einfachen Befehl umount /mnt/srcohne jegliche Nebeneffekte ausgehängt werden.

Was kann getan werden, um das aktuelle Problem zu beheben?

Um dies richtig zu machen, ohne die tatsächlichen ursprünglichen Mountpunkte zu beeinträchtigen, sollte man alle problematischen Mounts alsPrivatsodass sie ausgehängt werden können, ohne den ursprünglichen Einhängepunkt zu beeinträchtigen.

Ich mache hier ein Beispiel (alles alsWurzelBenutzer) und ahmt damit den Fall des OP nach, wo er Folgendes getan hat:

# mkdir -p /mnt/src
# mount --bind -o ro / /mnt/src

Und dann später (an einem Ort, der nicht schädlich sein kann):

# mkdir -p /root/intheway
# mount -t tmpfs tmpfs /root/intheway

was dann zu:

# umount /mnt/src
umount: /mnt/src: target is busy.

Identifizieren Sie problematische Halterungen mithilfe vonfindmnt:

# findmnt --kernel --submounts --list -o +PROPAGATION /mnt/src
TARGET                  SOURCE     FSTYPE  OPTIONS                        PROPAGATION
/mnt/src                /dev/vda2  ext4    ro,relatime,errors=remount-ro  shared
/mnt/src/root/intheway  tmpfs      tmpfs   rw,relatime,inode64            shared

Stellen Sie alle gefundenengeteiltmontiert alsPrivat, einschließlich /mnt/src:

# mount --make-private /mnt/src/root/intheway
# mount --make-private /mnt/src

demontieren (in umgekehrter Reihenfolge der Reihenfolge, in der sie montiert werden, wenn es mehrere Tiefen gibt), und abschließend mit/mnt/src
```
# umount /mnt/src/root/intheway
# umount /mnt/src
```

Die (gemeinsame) Halterung, die im Weg war, wurde dadurch nicht gestört:

# findmnt --kernel --list -o +PROPAGATION /root/intheway
TARGET         SOURCE FSTYPE OPTIONS             PROPAGATION
/root/intheway tmpfs  tmpfs  rw,relatime,inode64 shared

Answer 1

Das Problem

/mnt/srcnimmt keinen Speicherplatz ein, aber Sie sollten es aushängen, um einige Tools, einschließlich Tools, die Backups durchführen, nicht zu verwirren. lsblkWählt beispielsweise die Anzeige des ersten passenden Mounts und zeigt /mnt/srcstattdessen /für an /dev/vda2, was nicht optimal ist.

Die meisten Linux-Systeme laufensystemdalso nehme ich an, dass dieses System läuftsystemd.

systemdremontiert / alsgeteiltmount anstelle des Standardwerts des Linux-Kernels vonPrivat. Die Kernel-Dokumentation zur Mount-Propagation finden Sie hier:Gemeinsam genutzte Teilbäume. Das bedeutet, dass wenn später zusätzliche Mounts hinzugefügt (oder entfernt und wieder hinzugefügt) werden, diese ebenfalls automatisch durch den Propagierungsmechanismus /gemountet werden , und/mnt/srcseit seinergeteilt(stattSklave) Wenn Sie versuchen, sie von zu trennen, /mnt/srcwerden sie auch von/, die entweder fehlschlagen (weil sie von Prozessen verwendet werden) oder bei Erfolg möglicherweise Schaden anrichten (sie verschwinden auch von ihrem ursprünglichen Einhängepunkt).

Was hätte getan werden sollen?

Führen Sie solche Bind-Mounts immer mit demPrivatPropagierungsoption. Wenn Sie dabei sind und es zu Sicherungszwecken verwenden, lassen Sie auch die Bind-Einbindung schreibgeschützt (neu) einbinden:

mount --bind --make-private -o ro / /mnt/src

Auf diese Weise wird keine weitere Interaktion mit anderenAnschlüssewird passieren und dies kann jederzeit mit einem einfachen Befehl umount /mnt/srcohne jegliche Nebeneffekte ausgehängt werden.

Was kann getan werden, um das aktuelle Problem zu beheben?

Um dies richtig zu machen, ohne die tatsächlichen ursprünglichen Mountpunkte zu beeinträchtigen, sollte man alle problematischen Mounts alsPrivatsodass sie ausgehängt werden können, ohne den ursprünglichen Einhängepunkt zu beeinträchtigen.

Ich mache hier ein Beispiel (alles alsWurzelBenutzer) und ahmt damit den Fall des OP nach, wo er Folgendes getan hat:

# mkdir -p /mnt/src
# mount --bind -o ro / /mnt/src

Und dann später (an einem Ort, der nicht schädlich sein kann):

# mkdir -p /root/intheway
# mount -t tmpfs tmpfs /root/intheway

was dann zu:

# umount /mnt/src
umount: /mnt/src: target is busy.

Identifizieren Sie problematische Halterungen mithilfe vonfindmnt:

# findmnt --kernel --submounts --list -o +PROPAGATION /mnt/src
TARGET                  SOURCE     FSTYPE  OPTIONS                        PROPAGATION
/mnt/src                /dev/vda2  ext4    ro,relatime,errors=remount-ro  shared
/mnt/src/root/intheway  tmpfs      tmpfs   rw,relatime,inode64            shared

Stellen Sie alle gefundenengeteiltmontiert alsPrivat, einschließlich /mnt/src:

# mount --make-private /mnt/src/root/intheway
# mount --make-private /mnt/src

demontieren (in umgekehrter Reihenfolge der Reihenfolge, in der sie montiert werden, wenn es mehrere Tiefen gibt), und abschließend mit/mnt/src
```
# umount /mnt/src/root/intheway
# umount /mnt/src
```

Die (gemeinsame) Halterung, die im Weg war, wurde dadurch nicht gestört:

# findmnt --kernel --list -o +PROPAGATION /root/intheway
TARGET         SOURCE FSTYPE OPTIONS             PROPAGATION
/root/intheway tmpfs  tmpfs  rw,relatime,inode64 shared

Das Einhängen einer Bind-Quelle funktioniert nicht und das Gerät hat nicht genügend Speicherplatz

Antwort1

Das Problem

Was hätte getan werden sollen?

Was kann getan werden, um das aktuelle Problem zu beheben?

verwandte Informationen