Il arrive que les chemins des fichiers de données d'une application soient codés en dur, sans aucun mécanisme permettant de les ignorer. Pour ne pas avoir à modifier le code de l'application, vous pouvez utiliser des liens symboliques.
Supposons que l'application nomme son fichier de données en utilisant le nom de chemin codé en dur /etc/mydatafile. Vous pouvez remplacer ce nom par un lien symbolique dont la valeur désigne un fichier dans lequel figure les systèmes de fichiers de l'hôte logique. Par exemple, un lien symbolique vers /global/phys-schost-2/mydatafile.
Un problème peut survenir avec l'utilisation des liens symboliques si l'application, ou l'une de ses procédures administratives, modifie le nom du fichier de données, ainsi que son contenu. Supposons que l'application mette à jour un fichier en créant un nouveau fichier temporaire /etc/mydatafile.new, puis en lui donnant le nom du fichier initial, à l'aide de l'appel système rename() (ou de la commande mv). La démarche adoptée par le service de données (créer un fichier temporaire, puis le renommer) vise à garantir que le contenu de son fichier de données sera toujours bien formé.
Malheureusement, l'action rename() détruit le lien symbolique. Le nom /etc/mydatafile désigne alors un fichier standard qui réside sur le même système de fichiers que le répertoire /etc, et non dans le système de fichiers du cluster. Comme le système de fichiers /etc est propre à chaque hôte, les données ne sont pas disponibles après un basculement ou une commutation.
Le problème est le suivant : l'application ne « reconnaît » pas le lien symbolique – elle n'a d'ailleurs pas été écrite pour gérer ce type de lien. Pour rediriger un accès aux données au sein des systèmes de fichiers de l'hôte logique à l'aide de liens symboliques, la mise en œuvre de l'application doit adopter un comportement qui ne supprime pas les liens symboliques. Les liens symboliques ne constituent donc pas la solution parfaite au problème du stockage des données dans les systèmes de fichiers du cluster.