rename() sur l'atomicité NFS

J'ai un processus qui :

• écrit un nouveau fichier '.tmp'.
• utilise un rename() syscall pour remplacer un fichier existant.
• Ce fichier est accessible depuis un client NFS distant.

Nous faisons cela, parce que nous voulons des mises à jour atomiques des fichiers, et la fonction rename() Le spécimen dit :

Si newpath existe déjà, il sera remplacé de manière atomique, de sorte que il n'y a pas de moment où un autre processus tentant d'accéder au newpath ne le trouvera pas. Cependant, il y aura probablement une fenêtre dans laquelle oldpath et newpath font tous deux référence au fichier en cours de renommé.

Nous comptons sur ce comportement.

Mais voici le problème : tout récemment, depuis que nous avons migré vers un nouveau NetApp (mode Cluster, à partir du mode 7), nous avons un processus qui tombe très occasionnellement en panne avec ENOENT - aucun fichier ou répertoire de ce type.

Par "très occasionnellement", j'entends 4 ou 5 fois au cours des dernières semaines, dans le cadre d'un processus qui se déroule toutes les 5 minutes environ.

J'enquête auprès du fournisseur pour savoir s'il s'agit d'un bogue ou non avec leur serveur NFS.

Mais ce que j'essaie de comprendre, c'est si cette garantie d'atomicité est réellement applicable à NFS. Est-ce que quelqu'un est en mesure de clarifier pour moi si rename() La garantie d'atomicité de l'utilisateur s'applique-t-elle aux scénarios NFS multi-clients ? Je ne suis pas vraiment sûr que cette fonctionnalité ait fonctionné, mais qu'elle n'ait jamais été garanti en premier lieu.

De : RFC1813

La procédure RENAME renomme le fichier identifié par from.name dans le répertoire, from.dir, en to.name dans le répertoire, to.dir. L'opération doit être atomique pour le client. client.

Au cas où cela serait pertinent, nous avons des clients SL 6.5 qui utilisent des datastores NFS sur ONTAP-CDOT 8.3.