Comment résoudre les descripteurs de fichiers NFS obsolètes après avoir renommé un jeu de données

Les descripteurs de fichiers NFS obsolètes après le changement de nom d’un jeu de données signifient généralement que le client conserve encore des références vers des objets ou des identités d’exportation qui ont changé sur le serveur.

La récupération la plus sûre consiste à déterminer si un seul client est obsolète ou si l’identité de l’exportation elle-même a changé, à arrêter les applications qui utilisent activement le point de montage, à vérifier que le jeu de données renommé est exporté depuis le chemin prévu, puis à remonter les clients dans un ordre contrôlé. Ne redémarrez pas toutes les machines et ne recréez pas le jeu de données tant que vous ne savez pas si le descripteur obsolète concerne un seul montage client mis en cache ou tous les clients qui accèdent à l’exportation renommée.

Confirmer que l’erreur a commencé lors du changement de nom du jeu de données

Notez l’ancien nom et l’ancien point de montage du jeu de données, son nouveau nom et son nouveau point de montage, le chemin exporté ainsi que la première opération client ayant renvoyé ESTALE. Comparez un client affecté avec un client ayant monté le partage seulement après le changement de nom.

Un article récent de dépannage NFS explique que l’obsolescence signifie que le descripteur a changé, et n’indique pas simplement que le chemin réseau est indisponible.

Si le montage d’un client récent fonctionne tandis que celui d’un ancien client échoue, l’exportation renommée est probablement accessible et le problème immédiat vient de l’état mis en cache sur l’ancien client. Si les nouveaux montages échouent également, poursuivez l’analyse de l’exportation du serveur et de l’identité du jeu de données.

Vérifier que l’exportation pointe maintenant vers le bon jeu de données

Vérifiez la liste active des exportations du serveur et la table des montages du système de fichiers après le changement de nom. Un chemin peut continuer d’exister tout en désignant désormais un autre jeu de données, un point de montage vide ou un répertoire situé sous le mauvais système de fichiers.

OneUptime indique que les modifications d’exportation peuvent invalider les descripteurs lorsque des objets, des exportations, des identifiants de systèmes de fichiers ou des données restaurées changent sous une référence client existante.

Corrigez la cible de l’exportation avant d’intervenir sur les clients. Un remontage vers le mauvais chemin côté serveur peut sembler résoudre ESTALE tout en redirigeant silencieusement les applications vers une autre arborescence de répertoires.

Arrêter les processus qui utilisent encore l’ancien montage

Utilisez les outils de montage et de gestion des processus du client pour identifier les shells, serveurs multimédias, tâches de sauvegarde, conteneurs ou processus de base de données qui ont encore l’ancien montage NFS ouvert. Arrêtez le service concerné le moins largement possible avant de forcer le démontage.

Un guide de récupération Linux ciblé recommande de rechercher les processus avant le remontage, afin qu’une étape de récupération ne laisse pas un processus dans une vue du système de fichiers partiellement détachée.

Si un seul conteneur possède le chemin obsolète, arrêtez d’abord ce conteneur. Si le montage est partagé par de nombreux services, planifiez une courte fenêtre de maintenance au lieu de recourir immédiatement à des démontages différés sur une pile applicative active.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Remonter le client une fois le chemin du serveur stabilisé

Une fois l’exportation du serveur corrigée et les services dépendants arrêtés, démontez puis remontez le partage NFS sur un client de test. Utilisez la même adresse serveur, le même chemin d’exportation, la même version NFS et les mêmes options de montage que celles qui resteront en production.

Un cas de migration NFS montre que les clients ont besoin d’un nouveau montage après un déplacement du stockage, même lorsque les autorisations et les données copiées sont correctes.

Testez l’affichage du contenu d’un répertoire, une lecture, une écriture réversible et le chemin réel de l’application avant de remonter les autres clients. Si le même client devient immédiatement obsolète, revenez à l’identité du serveur plutôt que de répéter le remontage.

Vérifier si le changement de nom a modifié l’identité du descripteur de fichier

Les descripteurs de fichiers NFS ne sont pas de simples chaînes de chemin. Ils encodent une identité définie par le serveur pouvant inclure des informations liées au système de fichiers et aux inodes. Le remplacement, la restauration ou le déplacement du système de fichiers sous-jacent peut donc avoir de l’importance, même lorsque le chemin d’exportation visible semble similaire.

Une analyse approfondie des descripteurs de fichiers montre que les descripteurs associent une identité serveur et ne fonctionnent pas comme des signets vers un chemin textuel.

Si le changement de nom faisait en réalité partie d’une suppression et recréation, d’une réception, d’un clonage ou d’une restauration du jeu de données, documentez cette modification d’identité plus large. La bonne solution peut être de remonter tous les clients de manière coordonnée plutôt que d’essayer de préserver indéfiniment les anciens descripteurs.

Vérifier que chaque client utilise la nouvelle exportation après un redémarrage

Une fois le premier client validé, remontez les autres clients un par un, réactivez les services dépendants et vérifiez que leurs unités de montage configurées ou leurs chemins de liaison de conteneurs référencent la bonne exportation. Redémarrez ensuite un client non critique pour tester la persistance.

Un article de dépannage du stockage explique que les montages obsolètes persistent au-delà des applications tant que les processus qui les utilisent et l’état du montage n’ont pas été effectivement actualisés.

La réparation est terminée lorsque les clients fraîchement montés et redémarrés montent tous le jeu de données renommé sans erreur ESTALE et que les applications lisent les fichiers attendus. Le guide ZimaSpace associé sur les chemins de montage stables pour les serveurs personnels constitue l’étape complémentaire lorsque le changement de nom du jeu de données a également modifié les chemins de liaison locaux ou ceux des applications.

Questions fréquentes

Un descripteur de fichier NFS obsolète peut-il indiquer que le disque est défaillant ?

Pas à lui seul. ESTALE signifie que le descripteur mis en cache par le client n’identifie plus l’objet côté serveur auquel il s’attend. Vérifiez séparément l’état du stockage si le serveur signale également des erreurs d’E/S ou de système de fichiers.

Le redémarrage du service NFS résout-il toujours le problème ?

Non. Si l’exportation pointe désormais vers une autre identité de jeu de données, les anciens descripteurs du client restent incorrects. Vérifiez d’abord l’exportation, puis actualisez volontairement les montages clients.

Faut-il redémarrer tous les clients après le changement de nom d’un jeu de données ?

En général, non. L’arrêt contrôlé des services et le remontage suffisent lorsque l’exportation du serveur est correcte. Ne redémarrez un client que s’il ne parvient pas à libérer proprement le montage obsolète ou pour effectuer un dernier test de persistance.