Y a-t-il des inconvénients à utiliser mount --bind comme substitut aux liens symboliques?
Les liens symboliques ont des limitations dans la façon dont des fonctions telles que ls, mv et cp peuvent les utiliser car, contrairement aux commandes lancées par Shell comme cd, ces fonctions n'ont pas des informations sur la façon dont l'utilisateur a accédé à l'annuaire par rapport au chemin logique (voir la section post ). Il semble que l’utilisation du mount --bind L'option à la place peut contourner cela, offrant une fonctionnalité et une compatibilité accrues avec Samba et d'autres serveurs de fichiers car le répertoire monté aura alors deux chemins physiques indépendants, au lieu d'un lien.
Je voudrais remplacer tous mes liens symboliques par des références en utilisant le mount --bind option mais cela signifierait monter plus de 150 points dans fstab. Y a-t-il des problèmes de performances qui pourraient potentiellement résulter de cela ou de tout autre inconvénient que je devrais considérer?
Avec mount --bind, une arborescence de répertoires existe à deux endroits (ou plus) de la hiérarchie des répertoires. Cela peut provoquer un certain nombre de problèmes. Les sauvegardes et autres copies de fichiers sélectionneront toutes les copies. Il devient difficile de spécifier que vous souhaitez copier un système de fichiers: vous finirez par copier deux fois les fichiers montés sur la liaison. Recherches avec find, grep -r, locate, etc., traversera toutes les copies, etc.
Vous n'obtiendrez aucune "fonctionnalité et compatibilité accrues" avec les montures de liaison. Ils ressemblent à n'importe quel autre répertoire, ce qui la plupart du temps n'est pas un comportement souhaitable. Par exemple, Samba expose les liens symboliques en tant que répertoires par défaut; il n'y a rien à gagner à utiliser une monture bind. D'un autre côté, les montages de liaison peuvent être utiles pour exposer les hiérarchies de répertoires sur NFS.
Vous n'aurez aucun problème de performances avec les montures de liaison. Vous aurez des maux de tête liés à l'administration. Les montages Bind ont leur utilité, comme rendre une arborescence de répertoires accessible à partir d'un chroot, ou exposer un répertoire caché par un point de montage (il s'agit généralement d'une utilisation transitoire pendant le remodelage d'une structure de répertoire). Ne les utilisez pas si vous n'en avez pas besoin.
Seul root peut manipuler les montures de liaison. Ils ne peuvent pas être déplacés par des moyens ordinaires; ils verrouillent leur emplacement et les répertoires des ancêtres.
De manière générale, si vous passez un lien symbolique à une commande, la commande agit sur le lien lui-même s'il opère sur des fichiers, et sur la cible du lien s'il opère sur le contenu d'un fichier. Cela vaut aussi pour les répertoires. C'est généralement la bonne chose. Certaines commandes ont des options pour traiter les liens symboliques différemment, par exemple ls -L, cp -d, rsync -l. Quoi que vous essayiez de faire, il est beaucoup plus probable que les liens symboliques soient le bon outil, que les montures de liaison soient le bon outil.
En plus de ce que @Gilles a écrit plus tôt, il convient de noter que certains utilitaires pourraient considérer un répertoire monté par liaison comme un système de fichiers séparé. Cela peut avoir des implications en termes de performances ou de fonctionnalités si le programme ne peut plus supposer que le même numéro d'inode fait référence au même fichier (ce qu'il ne fait pas, s'ils se trouvent sur des systèmes de fichiers différents), un déplacement ne peut pas être optimisé comme lien vers ciblez puis dissociez la source, etc.
Vous devez également utiliser des montages de liaison au lieu de liens symboliques lorsque vous comptez sur un support qui n'est pas toujours en place (par exemple un disque externe) et que vous voulez être sûr que la structure de répertoire d'origine est en place même si le support échoue ou est supprimé.
Par exemple, si je veux conserver/var/tmp sur une carte sd, j'utiliserai le montage bind, car certains programmes s'attendront à ce que/var/tmp soit un répertoire valide même si la carte est retirée.
J'ai essayé bind mount pour contourner un problème d'installation de certains packages avec pacman (archlinux, plus à ce sujet ici ) sur un système où /var (aussi bien que /home et /usr/local) étaient des liens symboliques (entre les systèmes de fichiers: SSD vers SATA).
Cela avait l'air bien au début, mais, comme l'a souligné Gilles, locate a toujours donné plusieurs résultats pour un seul fichier, malgré le Prune_BIND_MOUNTS = "yes" faire la queue /etc/updatedb.conf.
$ 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
En creusant un peu plus loin, j'ai trouvé que les montures de liaison plus complexes peuvent être élaguées correctement:
$ 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
Sans l'option Prune_BIND_MOUNT, j'aurais obtenu 3 résultats:
$ 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
Un autre problème avec les montures de liaison:
Bien sûr, on peut ajouter manuellement des montures de liaison (mounpoint ou target) à PRUNEPATHS in /etc/updatedb.conf.
De plus, mountpoint et diverses commandes ou fonctions stat peuvent être utilisées dans les outils pour améliorer la traversée du système de fichiers comme proposé ici
Je l'utilise comme ceci:
/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
Je le fais pour réduire les écritures sur un SSD qui est monté avec defaults,relatime,data=ordered,commit=600 0 1 également symlinked dossiers vers mon ~ qui ne sont pas IO critique.
En ce qui concerne les montages de liaison de fichiers, ils se comportent plus près des liens durs que des liens symboliques. Cela peut avoir des conséquences quelque peu subtiles, par exemple:
# 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
Jusqu'ici tout va bien, mais considérez maintenant combien de programmes (éditeurs, scripts correctement écrits, etc.) modifient réellement les fichiers:
# echo 1new > 1new.txt
# mv 1new.txt 1.txt
# cat 1.txt
1new
# cat 2.txt
1a
Si 2.txt avait été un lien symbolique vers 1.txt alors la dernière commande aurait sorti 1new, ce à quoi on pourrait s'attendre.
Cela peut causer des problèmes subtils: dans systemd, j'utilisais BindReadOnlyPaths= pour qu'un service particulier utilise un autre resolv.conf fichier que le reste du système, mais cela s'est avéré floconneux de façon étrange et difficile à diagnostiquer parce que resolvconf serait remplacer le fichier source derrière le service.