:Problèmes connus sur les clients NFS

Versions Linux recommandées

Pour assurer la stabilité du système, nous vous conseillons d'utiliser les images officielles d'Alibaba Cloud dont les versions de noyau ont été rigoureusement testées et validées. Pour plus d'informations, consultez la rubrique Images de noyau recommandées.

Échecs de réponse NFS dus à un bogue du noyau dans les piles réseau (priorité : élevée)

Un échec de réponse NFS provoqué par une erreur de la pile réseau se produit lorsqu'un serveur NFS ne parvient pas à traiter une requête envoyée de manière répétée par le noyau. Ce problème peut apparaître avec les versions de noyau suivantes : de 2.6.32-296 à 2.6.32-696.10.1, à l'exception de la version 2.6.32-696.10.1.

Si le message « operation failed » s'affiche, nous vous recommandons de redémarrer l'instance Elastic Cloud Service (ECS) sur laquelle réside le client. Pour plus de détails, consultez la page RHEL6.9:NFSv4 TCP transport stuck in FIN_WAIT_2 forever.

Échecs de réponse NFS dus à un bogue du noyau (priorité : élevée)

• Un échec de réponse NFS survient si un basculement du serveur NFS se produit après le démarrage d'un client NFS connecté ou lors de lectures ou d'écritures de données dans un système de fichiers via ce client. Le basculement entraîne un interblocage (deadlock). Ce problème peut se produire avec les versions de noyau suivantes :

  • RHEL 6 ou CentOS 6 2.6.32-696.3.1.el6

  • RHEL 7 ou CentOS 7 3.10.0-229.11.1.el7 et versions antérieures

  • Ubuntu 15.10 : Linux 4.2.0-18-generic

  En cas d'affichage du message « operation failed », il est recommandé de redémarrer l'instance ECS hébergeant le client. Pour en savoir plus, reportez-vous à la documentation RHEL7:NFSv4 client loops with WRITE/NFS4ERR_STALE_STATEID - if NFS server restarts multiple times within the grace period.

• Une défaillance de réponse NFS peut également survenir en cas de partitionnement ou d'instabilité du réseau, ou si le client NFS ne gère pas correctement les codes d'erreur renvoyés. Ces événements réseau provoquent des reconnexions répétées. Lorsque ce problème se manifeste, le message d'erreur « bad sequence-id » apparaît de façon récurrente dans les journaux système. Les versions de noyau concernées sont les suivantes :

  • RHEL 6 ou CentOS 6 2.6.32-696.16.1.el6 et versions antérieures

  • RHEL 7 ou CentOS 7 3.10.0-693.el7 et versions antérieures

  Si le message « operation failed » s'affiche, redémarrez l'instance ECS sur laquelle le client est installé. Consultez la ressource suivante pour plus d'informations : RHEL6/RHEL7:NFS4 client receiving NFS4ERR_BAD_SEQID drops nfs4 stateowner resulting in infinite loop of READ/WRITE+NFS4ERR_BAD_STATEID.

• Un retard ou un échec de réponse NFS se produit lors de l'exécution de la commande ls, des commandes utilisant les caractères génériques * ou ?, ou de toute autre commande nécessitant un parcours de répertoire. Ce problème affecte les versions de noyau CentOS et RHEL 5.11.x.

  Pour résoudre ce problème, nous vous recommandons de mettre à niveau le noyau vers la dernière version disponible.

Commande chown et appels API système non pris en charge (priorité : faible)

Si la version du noyau est 2.6.32, la commande chown et les appels API système ne sont pas pris en charge sur un client NFS.

Commande ls bloquée dans une boucle infinie (priorité : faible)

• Avec une version de noyau égale ou antérieure à 2.6.32-696.1.1.el6, la commande ls entre dans une boucle infinie. Ce phénomène se produit si vous créez ou supprimez des fichiers ou sous-répertoires pendant l'exécution de la commande ls.

  Il est conseillé de mettre à niveau le noyau vers la dernière version pour corriger ce problème.

• Si votre distribution Linux utilise le noyau 4.18.0-305.12.1, les commandes nécessitant un parcours de répertoire (telles que ls) restent bloquées dans une boucle infinie. Pour résoudre cette situation, mettez à niveau le noyau vers la version 4.18.0-305.19.1 ou une version ultérieure.