ln -s vs mount --bind

19

Y a-t-il une différence pratique entre l'utilisation de ln -sou mount --bind?

Je souhaite déplacer certains dossiers vers une autre partition, sans modifier leur paramètre de démon, et je me demande quelle approche je dois adopter.

Je préfère ln -scar cela nécessite une configuration minimale (pas de /etc/fstabmodifications), mais peut-être qu'il y a une raison pour laquelle ce n'est pas courant?

— SyRenity
source

25

Putain, oui. Si vous exécutez le, ln -svous créez un lien symbolique, qui est un inode pointant vers un certain objet du système de fichiers, c'est pourquoi les liens symboliques peuvent traverser les systèmes de fichiers et les liens matériels ne le peuvent pas: les liens matériels n'ont pas leur propre inode.

Si vous montez un système de fichiers avec --bind, vous créez un deuxième point de montage pour un périphérique ou un système de fichiers.

Si vous envisagez un lien symbolique comme une redirection, envisagez un --bindsystème de fichiers monté comme créant une autre passerelle vers les données.

Les liens symboliques et les montures de liaison sont un tout autre jeu de balle.

Le --bindmontage me semble un peu plus robuste et il est probablement un peu plus rapide que de travailler avec un lien symbolique. D'un autre côté, il n'y a pas d'inconvénients sérieux à utiliser le lien symbolique, car les performances seront faibles (si elles existent).

Edit : J'y ai pensé, et le hit de performance pourrait être un peu plus grand que je ne le pensais à l'origine. Si vous avez une application qui lit beaucoup de fichiers différents, chaque nouveau fichier ouvert nécessitera une lecture supplémentaire. Certaines recherches suggèrent ici que mon hypothèse est correcte, donc si vous avez une application IO lourde en cours d'exécution, envisagez l' --bindoption de monter au-dessus de la solution de lien symbolique.

La raison pour laquelle elle n'est pas courante, est probablement le fait qu'un lien symbolique est visible dans un ls, alors qu'un montage bind n'est visible que lorsque vous regardez / proc / mounts ou / etc / mtab (ce que fait la commande mount, si elle est exécuté sans paramètres). À part cela, je ne pense pas qu'il y ait de problème. Je serais intéressé s'il y en avait, cependant.

Addition : un autre problème avec ln -sest que pour certaines applications, lorsque le chemin est déréférencé, il peut faire reculer l'application s'il "s'attend" à ce que certains éléments soient à des endroits spécifiques.

— wzzrd
source

Merci pour l'explication complète! Une petite question complémentaire - quel est le paramètre --rbind et comment peut-il être utilisé? D'après le manuel, il semble que le paramètre supporte le montage des sous-supports dans l'arborescence montée est-ce correct? De plus, est-ce que --rbind suffit, ou dois-je faire --bind alors --rebind? Merci encore.

— SyRenity

2

mount, lorsqu'il est invoqué sans argument, imprime le contenu de /etc/mtab, qui contient des informations légèrement différentes de /proc/mounts. (En particulier, /proc/mounts(lien symbolique vers /proc/self/mounts) affiche toujours les points de montage visibles par le processus qui le

— lit.

1

@wzzrd - de la FAQ "Le meilleur de tous - éditez et améliorez les questions et réponses existantes!" :) .. ce n'est en aucun cas une légère réponse à votre réponse - c'est une petite amélioration avec des informations supplémentaires, pour lesquelles vous recevrez un représentant supplémentaire si / quand il sera voté :)

— warren

1

@warren, tant pis, je ne suis pas en colère :) c'est juste que tu as ajouté quelque chose dont je n'ai aucune idée, donc

— c'était

2

@wzzrd - ne voulait pas marcher sur les orteils :) ... le problème spécifique à l'application est quelque chose que j'ai rencontré avec le produit principal que j'utilise

— warren

6

L'une des grandes différences entre ln -set un montage de liaison est que vous pouvez utiliser un montage de liaison pour "modifier" un système de fichiers en lecture seule. Par exemple, s'il y avait un CD monté /mnt/applicationet que vous vouliez le remplacer /mnt/application/badconfigfile.confpar une version correcte, vous pourriez faire ceci:

mount -o bind /path/to/correct/file.conf /mnt/application/badconfigfile.conf

Il ne serait pas possible d'affecter la même modification à l'aide d'un lien symbolique car vous ne pouvez pas modifier le système de fichiers cible.

Cela peut également être utilisé à bon escient si vous avez distribué une suite commune de logiciels via NFS (ou une sorte de système de fichiers de cluster) et que vous souhaitez apporter des modifications spécifiques à l'hôte sur un seul système. Vous pouvez simplement utiliser un montage de liaison sur le système cible pour remplacer les fichiers ou répertoires si nécessaire.

— larsks
source

Économiseur de maux de tête! (cas rare, mais mérite d'être rappelé pour ce moment spécial)

— Jonathan Komar

2

Différence pratique n ° 1 pour moi entre ln -s et mount --bind:

vsftpd ne permet pas de parcourir un répertoire via un lien symbolique, mais le permet lorsqu'il est monté.

Je ne sais pas quel démon vous utilisez, mais il peut se comporter de la même manière.

— petrus
source

1

On peut noter qu'en raison de la liaison à une monture, qui est elle-même une liaison, qui est plus tard rebondie, la liaison d'origine reste intacte, en supposant que tout reste physiquement connecté.

Autrement dit, si lier A à B et lier B à C, puis lier D à B, C sera toujours lié à A. C'est peut-être ce que vous voulez, ou non. Si l'on souhaite que C suive B, remontez en utilisant les mêmes cibles, c'est mount -o remount B C-à- dire , ou utilisez à la --rbindplace. Il n'y a pas d' --rebindoption.

— Wiley
source