Cache NFS: le contenu du fichier n'est pas mis à jour sur le client lorsqu'il est modifié sur le serveur

11

Voici ma configuration: une machine serveur NFS (v4), plusieurs machines client NFS.

Lorsqu'un ordinateur client écrit des fichiers sur le montage NFS, les autres clients voient instantanément le nouveau contenu: pas de problème.

Mais, lorsque la machine serveur modifie le contenu du fichier, ce nouveau contenu n'est pas affiché sur le client jusqu'à ce que je fasse un lsdu répertoire à partir du client.

Je suis absolument perplexe sur cette incohérence ... toute aide serait grandement appréciée!

Infos:

nfs 1.2.3-r1 sur le client et le serveur
acregmin, acregmax, acdirmin, acdirmax, lookupcache: valeurs par défaut

nfs

— nombrexiii
source

1

Pouvez-vous faire une petite expérience pour plus d'informations?: Faites une ls -isur le client avant de modifier le fichier sur le serveur, puis à nouveau après. Voyez si les chiffres changent. S'ils le font parce que le serveur remplace le fichier et que le client ne le remarque pas jusqu'à ce qu'il réanalyse le répertoire. Si c'est le cas, essayez de définir l'option de montage lookupcache=noneet voyez si le comportement change.

— Patrick

2

Désolé pour le retard. L'inode change efficacement. J'ai ajouté l'option lookupcache, cela semble fonctionner. Je vérifierai à nouveau demain.

— numberxiii

11

Ajout en tant que réponse sur la base de votre commentaire.
La solution consiste à ajouter lookupcache=noneà vos options de montage nfs.

Ce qui se passe, c'est que la première fois que votre client lit le fichier, il effectue une recherche NFS pour obtenir l'ID de fichier NFS. Il met ensuite en cache l'ID de fichier NFS, et lorsque vous revenez pour ouvrir le fichier, il utilise le cache. Normalement, ce n'est pas un problème car lorsque le fichier est mis à jour, son ID de fichier reste le même. Mais pour une raison quelconque, l'ancien fichier est supprimé et un nouveau est créé (ou renommé, ou quelque chose là où ce n'est pas le même fichier).
Normalement, ce n'est pas un problème non plus car lorsque votre client essaie d'ouvrir un ID de fichier qui n'y est pas, il obtiendra une erreur du serveur et effectuera une autre recherche pour obtenir le nouvel ID de fichier. Mais pour une raison quelconque, le serveur NFS laisse le client ouvrir cet ancien ID de fichier. Peut-être qu'un autre client a ouvert le fichier et qu'il n'est donc pas encore supprimé, je ne sais pas.

Dans tous les cas, la façon de le résoudre est de dire au client de toujours faire un nfslookup avant d'ouvrir un fichier en utilisant l'option de montage nfs lookupcache=none. L'inconvénient est que cela peut être coûteux si vous ouvrez fréquemment des fichiers car cela ajoute plus de trafic au serveur NFS.

— Patrick
source

Merci pour votre explication. Sur le serveur NFS, la pile du répertoire exporté est DRBD / LVM / ext4. C'est peut-être à l'origine du "bug". J'ai le problème sur plusieurs clients, mais pas sur certains autres ... Je vais refaire tous mes tests et vous dire si tout va bien avec cette option.

— numberxiii

0

Modifiez l'option de montage sur hard,intr. je pense que la valeur par défaut peut être douce dans votre système. CA aidera.

— johnshen64
source

malheureusement, l'ajout de ces options de montage n'a rien changé :(

— numberxiii

Pour mon premier test, je fais un remontage. Ensuite, j'ai fait un test à partir d'un autre client, avec un montage propre. Le problème semble être corrigé: nous attendons 30

— secondes

J'ai construit un nouveau client (vm) à vérifier: pas de problème avec le contenu!

— numberxiii

1

@ johnshen64 pourquoi pensez-vous que le problème serait résolu? Le matériel dur / mou ne concerne que l'interruption de connexion, n'a rien à voir avec la mise en cache.

— Patrick

0

Vous pouvez également actualiser manuellement le cache NFS avec

sudo mount /nfs-mount -o remount

... au cas où vous ne voudriez pas ajouter d'options de montage dégradant les performances.

— Janne
source