Le mv est-il atomique sur mon fs?

Comment puis-je vérifier si mvest atomique sur mon fs (ext4)?

Le système d'exploitation est Red Hat Enterprise Linux Server version 6.8.

En général, comment puis-je vérifier cela? J'ai regardé autour de moi et je n'ai pas trouvé si mon système d'exploitation était POSIX standard.

posix mv move

— Tizianoreica
source

As-tu essayé strace?

— Wildcard

Connexes: Est-ce qu'un unlinkou renameportable et atomique fera un linkéchec?

— Gilles 'SO- arrête d'être méchant'

Il est intéressant de noter que la réponse pourrait être: "Cela dépend".

Pour être clair, mvest spécifié pour

L' mvutilitaire doit effectuer des actions équivalentes à la rename() fonction

La spécification de la fonction de renommage indique:

Cette rename()fonction est équivalente pour les fichiers normaux à celle définie par la norme ISO C. Son inclusion ici étend cette définition pour inclure des actions sur les répertoires et spécifie le comportement lorsque le nouveau paramètre nomme un fichier qui existe déjà. Cette spécification nécessite que l'action de la fonction soit atomique.

Mais la dernière spécification ISO C pour les rename()états:

7.21.4.2 La renamefonction

Synopsis
#include <stdio.h>
int rename(const char *old, const char *new);
La description

La renamefonction fait que le fichier dont le nom est la chaîne pointée par oldest désormais connu sous le nom donné par la chaîne pointée par new. Le fichier nommé oldn'est plus accessible par ce nom. Si un fichier nommé par la chaîne pointée par newexiste avant l'appel à la renamefonction, le comportement est défini par l'implémentation.

Retour

La renamefonction renvoie zéro si l'opération réussit, différente de zéro en cas d'échec, auquel cas si le fichier existait auparavant, il est toujours connu sous son nom d'origine.

Étonnamment, notez qu'il n'y a pas d'exigence explicite d'atomicité. Il peut être requis ailleurs dans la dernière norme C accessible au public, mais je n'ai pas pu le trouver. Si quelqu'un peut trouver une telle exigence, les modifications et commentaires sont les bienvenus.

Voir aussi Rename () atomic?

Selon la page de manuel Linux :

S'il newpathexiste déjà, il sera atomiquement remplacé, de sorte qu'il n'y ait aucun point auquel un autre processus tentant d'accéder newpathle trouvera manquant. Cependant, il y aura probablement une fenêtre dans laquelle les deux oldpathet se newpathréfèrent au fichier à renommer.

La page de manuel Linux affirme que le remplacement du fichier sera atomique.

Tester et vérifier que l'atomicité peut être très difficile, cependant, si c'est jusqu'où vous devez aller. Vous ne savez pas ce que vous voulez dire dans votre utilisation de "Comment puis-je vérifier si mv est atomique". Voulez-vous des exigences / spécifications / documentation qu'il est atomique, ou avez-vous vraiment besoin de le tester ?

Notez également que ce qui précède suppose que les deux noms de fichiers d'opérande se trouvent dans le même système de fichiers. Je ne trouve aucune restriction standard sur l' mvutilitaire pour appliquer cela.

— Andrew Henle
source

Je dois m'assurer que ce mouvement est atomique. les tests sont-ils suffisants pour l'accepter? Je ne sais pas. Oui, je travaille sur un même fs (ext4 à ext4).

— Tizianoreica

POSIX ne garantit pas l'atomicité non plus, mais Linux, comme la plupart des variantes Unix, le fait, pour les systèmes de fichiers «natifs» tels que ext4.

— Gilles 'SO- arrête d'être méchant'

Étant donné que l'ISO C ne définit que le comportement d'un programme et non d'un système entier, il serait étrange qu'il dise quoi que ce soit sur l' renameatomicité.

— Gilles 'SO- arrête d'être méchant'

J'ai lu "cette spécification" comme faisant référence à la phrase précédente ("Son inclusion ici ... spécifie le comportement lorsque le nouveau paramètre nomme un fichier qui existe déjà"), qui fait référence à des parties antérieures du document POSIX ("un lien nommé new doit restent visibles par les autres threads tout au long ... et se réfèrent soit au fichier référencé par nouveau ou ancien ... "). En d'autres termes, POSIX promet de mettre en œuvre la norme ISO C et apporte des garanties supplémentaires au-delà de ce que propose ISO C. Cette interprétation est-elle utile?

— SimonJ

@Tizianoreica Je sais que c'est un post ancien, mais je viens de voir votre commentaire et j'ai pensé que je devrais clarifier: Le système de fichiers réel doit être le même pour que le renommage soit atomique. Pas seulement le même type de système de fichiers. Par exemple, si vous avez /un ext4 fs et /tmpun ext4 fs différent, vous ne pouvez pas atomiquement mv de l'un à l'autre.

— Wodin

mvest basé sur renameun appel système et rename()est atomique. Vous pouvez consulter la page de manuel rename(2).

Vous pourriez trouver une réponse sur Is rename () atomic? sur stackoverflow.

Quel type de fs avez-vous utilisé?

— xtrmz
source

fs est ext4 - os déjà spécifié.

— Tizianoreica

-1

En plus de vérifier les appels système et leur atomicité, peut-être inotify-toolspeut servir de test, bien que je ne sois pas sûr que ce soit une preuve garantie d'atomicité.

Ouvrez 2 coquilles. Regardez le répertoire cible du déménagement dans l'un d'eux:

inotifywait -m target/

Déplacez un fichier dans le répertoire de l'autre:

mv foobar target/

Le inotifywaitne doit afficher qu'une seule ligne:

target/ MOVED_TO foobar

Il semble atomique par rapport à la réponse à ls target/et touch target/a, qui produisent des messages multilignes comme:

# the response to ls target/
target/ OPEN,ISDIR 
target/ ACCESS,ISDIR 
target/ CLOSE_NOWRITE,CLOSE,ISDIR

Je pense, au moins, cela montre que la coopération multiprocessus asynchrone sur les fichiers est sûre avec inotify(pratiquement atomique): dans tous les cas, vous ne répondriez qu'après avoir inotifydonné le signal final après l'opération. Par exemple, une configuration producteur-consommateur peut être implémentée facilement et en toute sécurité avec inotify.

— xealits
source