it-swarm.com.de

Gibt es Nachteile bei der Verwendung von mount --bind als Ersatz für symbolische Links?

Symlinks haben Einschränkungen hinsichtlich der Funktionsweise von Funktionen wie ls, mv und cp, da diese Funktionen im Gegensatz zu von Shell initiierten Befehlen wie cd nicht verfügbar sind Informationen darüber, wie der Benutzer in Bezug auf den logischen Pfad auf das Verzeichnis zugegriffen hat (siehe verwandte post ). Es scheint, als könnte die Verwendung der Option mount --bind Dies umgehen und eine verbesserte Funktionalität und Kompatibilität mit Samba und anderen Dateiservern bieten, da das bereitgestellte Verzeichnis dann zwei unabhängige physische Pfade anstelle eines Links hat.

Ich möchte alle meine symbolischen Links durch Verweise mit der Option mount --bind Ersetzen, dies würde jedoch bedeuten, dass mehr als 150 Punkte in fstab eingefügt werden. Gibt es Leistungsprobleme, die möglicherweise aus diesem oder anderen Nachteilen resultieren könnten, die ich berücksichtigen sollte?

59
mrtrujiyo

Mit mount --bind existiert ein Verzeichnisbaum an zwei (oder mehr) Stellen in der Verzeichnishierarchie. Dies kann eine Reihe von Problemen verursachen. Backups und andere Dateikopien wählen alle Kopien aus. Es wird schwierig anzugeben, dass Sie ein Dateisystem kopieren möchten: Am Ende werden die am Binden bereitgestellten Dateien zweimal kopiert. Sucht mit find, grep -r, locate usw. durchlaufen alle Kopien und so weiter.

Sie erhalten keine "erhöhte Funktionalität und Kompatibilität" mit Bindemontagen. Sie sehen aus wie jedes andere Verzeichnis, was meistens kein wünschenswertes Verhalten ist. Beispielsweise stellt Samba symbolische Links standardmäßig als Verzeichnisse bereit. Mit einem Bind-Mount gibt es nichts zu gewinnen. Auf der anderen Seite können Bindungs-Mounts nützlich sein, um Verzeichnishierarchien über NFS verfügbar zu machen.

Sie haben keine Leistungsprobleme mit Bindungs-Mounts. Was Sie haben, sind Verwaltungsprobleme. Bindungs-Mounts haben ihre Verwendung, z. B. indem sie einen Verzeichnisbaum von einer Chroot aus zugänglich machen oder ein Verzeichnis verfügbar machen, das von einem Mount-Punkt ausgeblendet wird (dies ist normalerweise eine vorübergehende Verwendung, während eine Verzeichnisstruktur umgestaltet wird). Verwenden Sie sie nicht, wenn Sie keine Notwendigkeit haben.

Nur root kann Bindungs-Mounts manipulieren. Sie können nicht mit gewöhnlichen Mitteln bewegt werden; Sie sperren ihren Standort und die Ahnenverzeichnisse.

Wenn Sie einen symbolischen Link an einen Befehl übergeben, wirkt der Befehl im Allgemeinen auf den Link selbst, wenn er auf Dateien angewendet wird, und auf das Ziel des Links, wenn er auf Dateiinhalte angewendet wird. Dies gilt auch für Verzeichnisse. Dies ist normalerweise das Richtige. Einige Befehle haben Optionen, um symbolische Links unterschiedlich zu behandeln, z. B. ls -L, cp -d, rsync -l. Was auch immer Sie versuchen, es ist weitaus wahrscheinlicher, dass Symlinks das richtige Werkzeug sind, als Bindungs-Mounts das richtige Werkzeug.

Zusätzlich zu was @Gilles geschrieben hat früher, ist es erwähnenswert, dass einige Dienstprogramme ein bindgebundenes Verzeichnis als a betrachten könnten separates Dateisystem. Dies kann Auswirkungen auf die Leistung oder Funktionalität haben, wenn das Programm nicht mehr davon ausgehen kann, dass sich dieselbe Inode-Nummer auf dieselbe Datei bezieht (was nicht der Fall ist, wenn sie sich auf verschiedenen Dateisystemen befinden). Eine Verschiebung kann nicht als Link-at- optimiert werden Ziel-dann-Verknüpfung-Quelle usw.

14
a CVn

Sie sollten auch Bindungs-Mounts anstelle von Symlinks verwenden, wenn Sie sich auf eine Unterstützung verlassen, die möglicherweise nicht immer vorhanden ist (z. B. eine externe Festplatte), und Sie möchten sicherstellen, dass die ursprüngliche Verzeichnisstruktur auch dann vorhanden ist, wenn die Unterstützung vorhanden ist schlägt fehl oder wird entfernt.

Wenn ich beispielsweise/var/tmp auf einer SD-Karte behalten möchte, verwende ich den Bind-Mount, da einige Programme erwarten, dass/var/tmp ein gültiges Verzeichnis ist, selbst wenn die Karte entfernt wird.

6
TopperH

Ich habe versucht, bind mount zu umgehen, um ein Problem zu umgehen, bei dem einige Pakete mit pacman (archlinux, mehr dazu hier ) auf einem System installiert wurden, auf dem /var (Sowie /home Und /usr/local) Waren Symlinks (über Dateisysteme hinweg: SSD zu SATA).

Anfangs sah es großartig aus, aber wie Gilles betonte, lieferte locate trotz der Zeile Prune_BIND_MOUNTS = "yes" In /etc/updatedb.conf Immer mehrere Ergebnisse für eine einzelne Datei.

$ locate \*/findutils-4.4.2 | xargs ls -ldiog
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /SHARED/LOCALS/Manjaro/src/findutils-4.4.2
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /usr/local/src/findutils-4.4.2

Als ich etwas weiter grub, stellte ich fest, dass komplexere Bindungshalterungen möglicherweise richtig beschnitten werden:

$ Sudo mount --bind /SHARED/LOCALS/common/ /usr/local/common
$ findmnt | fgrep -n sdb
34:├─/SHARED/LOCALS                  /dev/sdb5           ext4           rw,relatime,data=ordered
35:│ └─/SHARED/LOCALS/Manjaro/common /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
36:├─/usr/local                      /dev/sdb5[/Manjaro] ext4            rw,relatime,data=ordered
37:│ └─/usr/local/common             /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
38:├─/SHARED/HOMES                   /dev/sdb4           ext4            rw,relatime,data=ordered
39:├─/home                           /dev/sdb4[/Manjaro] ext4            rw,relatime,data=ordered
40:├─/SHARED/VARS                    /dev/sdb3           ext4            rw,relatime,data=ordered
41:├─/var                            /dev/sdb3[/Manjaro] ext4            rw,relatime,data=ordered
42:└─/opt                            /dev/sdb5[/opt]     ext4            rw,relatime,data=ordered

$ Sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
Prune_bind_mounts\000
Rebuilding bind_mount_paths:
Matching bind_mount_paths:
Skipping `/SHARED/LOCALS/Manjaro/common': bind mount
Skipping `/usr/local/common': bind mount

$ locate \*/mmedia
/SHARED/LOCALS/common/mmedia

Ohne die Option Prune_BIND_MOUNT hätte ich 3 Ergebnisse erhalten:

$ Sudo sed -i '1 s/yes/no/' /etc/updatedb.conf 
$ Sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
Prune_bind_mounts\000
$ locate \*/mmedia
/SHARED/LOCALS/Manjaro/common/mmedia
/SHARED/LOCALS/common/mmedia
/usr/local/common/mmedia
$ Sudo sed -i '1 s/no/yes/' /etc/updatedb.conf 

Ein weiteres Problem mit Bind-Mounts:

Natürlich kann man PRUNEPATHS in /etc/updatedb.conf Manuell Bindungs-Mounts (Mounpoint oder Target) hinzufügen.

Außerdem können mountpoint und verschiedene stat Befehle oder Funktionen in Tools verwendet werden, um die Durchquerung des Dateisystems zu verbessern wie hier vorgeschlagen

1
RockyRoad

Ich benutze es so:

/mnt/sdb1/.user_cache/User1_cache /home/User1/.cache none bind 0 0
/mnt/sdb1/.user_cache/User2_cache /home/User2/.cache none bind 0 0

Ich mache es, um Schreibvorgänge auf eine SSD zu reduzieren, die mit defaults,relatime,data=ordered,commit=600 0 1 Eingehängt wird, und symlinked Ordner in meinen ~, Die nicht IO kritisch) sind .

0
rochr4

Wenn es um Dateibindungs-Mounts geht, verhalten sie sich eher wie Hardlinks als wie Symlinks. Dies kann subtile Konsequenzen haben, zum Beispiel:

# echo 1 > 1.txt
# touch 2.txt
# mount --bind 1.txt 2.txt
# cat 2.txt
1
# echo 1a > 1.txt
# cat 2.txt
1a

So weit so gut, aber jetzt überlegen Sie, wie viele Programme (Editoren, richtig geschriebene Skripte usw.) tatsächlich Dateien ändern:

# echo 1new > 1new.txt
# mv 1new.txt 1.txt
# cat 1.txt
1new
# cat 2.txt
1a

Wenn 2.txt Ein Symlink zu 1.txt Gewesen wäre, hätte der letzte Befehl 1new Ausgegeben, was man wahrscheinlich erwarten würde.

Dies kann einige subtile Probleme verursachen: In systemd habe ich BindReadOnlyPaths= verwendet, um einen bestimmten Dienst dazu zu bringen, eine andere resolv.conf - Datei als den Rest des Systems zu verwenden, aber das hat sich geändert auf seltsame und schwer zu diagnostizierende Weise schuppig zu sein, weil resolvconf die Quelldatei hinter dem ersetzen würde Service ist zurück.

0