La création d'un lien symbolique vers un autre lien symbolique a-t-elle des effets secondaires?
La création d'un lien symbolique vers un autre lien symbolique sur une boîte Linux a-t-elle des effets secondaires (en particulier en termes de performances)?
En général, non. Techniquement, il y aura un très léger impact sur les performances pour l'indirection, mais il ne sera pas perceptible par votre application. Par exemple, la plupart des bibliothèques partagées sont des liens symboliques vers des liens symboliques (par exemple, libQtCore.so -> libQtCore.so.4 -> libQtCore.so.4.7 -> libQtCore.so.4.7.1).
Il s'agit principalement d'un commentaire de l'argument de Daniel Gallagher, mais il ne tient pas dans la zone de commentaire, ce qui le rendra plus lisible. De Wikipedia sur les liens symboliques :
Les premières implémentations de liens symboliques stockaient les informations de lien symbolique sous forme de données dans des fichiers normaux. Le fichier contenait la référence textuelle à la cible du lien, et un indicateur [clarification nécessaire] le désignant comme un lien symbolique.
Cette méthode était lente et une utilisation inefficace de l'espace disque sur les petits systèmes. Une amélioration, appelée liens symboliques rapides, a permis de stocker le chemin cible dans les structures de données utilisées pour stocker les informations de fichier sur le disque (inodes). Cet espace stocke normalement une liste d'adresses de bloc de disque allouées à un fichier. Ainsi, les liens symboliques avec des chemins cibles courts sont rapidement accessibles. Les systèmes dotés de liens symboliques rapides recourent souvent à l'utilisation de la méthode d'origine si le chemin cible dépasse l'espace inode disponible. Le style original est appelé rétroactivement un lien symbolique lent. Il est également utilisé pour la compatibilité du disque avec d'autres versions ou des versions plus anciennes de systèmes d'exploitation.
Bien que le stockage de la valeur du lien à l'intérieur de l'inode enregistre un bloc de disque et une lecture de disque, le système d'exploitation doit toujours analyser le nom du chemin dans le lien, ce qui nécessite toujours la lecture d'inodes supplémentaires et nécessite généralement la lecture d'autres, et potentiellement de nombreux, répertoires, le traitement à la fois la liste des fichiers et les inodes de chacun d'eux jusqu'à ce qu'il trouve une correspondance avec les composants de chemin du lien. Ce n'est que lorsqu'un lien pointe vers un fichier du même répertoire que les "liens rapides" offrent des performances nettement meilleures que les autres liens symboliques.
Ainsi, la pénalité d'utiliser des liens symboliques vers des liens symboliques pour les bibliothèques dans /usr/lib est moins sévère que les recherches de chemin plus longues qui couvrent peut-être même plusieurs points de montage.
Je n'ai pas vu de chiffres bruts sur le sujet, mais d'après mon expérience personnelle, je dirais que c'est tout au plus un succès mineur, non perceptible dans la plupart des circonstances. Les résultats de performance en combinaison avec les liens symboliques dont j'ai entendu parler (pas vu en personne) ont été (probablement mauvais) implémentations où les fourches système sont utilisées pour trouver la cible d'un certain lien symbolique.
Je serais ravi de voir des commentaires "plus charnus" concernant les liens symboliques et les performances, car c'est la deuxième fois en quelques mois que je m'y intéresse sans arriver à une conclusion définitive.
effets secondaires
Oui. Vous ne pouvez empiler que des liens symboliques ensemble avant que le noyau et/ou l'application refusent de suivre la chaîne. (Parce que la détection de cycle est coûteuse en termes de mémoire, en particulier dans le noyau, aucun indicateur "vu" n'est utilisé et la profondeur de récursivité est plafonnée.)