Tout d'abord, dissipons certains mythes.
c'est atomique donc les incohérences ne peuvent pas arriver
Déplacer un fichier dans le même système de fichiers (c'est-à-dire rename
appel) système est atomique par rapport à l'environnement logiciel. L'atomicité signifie que tout processus qui recherche le fichier le verra soit à son ancien emplacement, soit à son nouvel emplacement; aucun processus ne pourra observer que le fichier a un nombre de liens différent, ou que le fichier est présent dans le répertoire source après avoir été présent dans le répertoire de destination, ou que le fichier est absent du répertoire cible après avoir été absent dans la source annuaire.
Cependant, si le système se bloque en raison d'un bogue, d'une erreur de disque ou d'une panne de courant, il n'y a aucune garantie que le système de fichiers est laissé dans un état cohérent, et encore moins que le déplacement n'est pas laissé à moitié fait. Linux n'offre généralement pas de garantie d'atomicité vis-à-vis des événements matériels.
vous copiez d'abord l'entrée dir dans le nouveau dir, puis vous effacez l'entrée sur le dir précédent, vous pouvez donc avoir l'incohérence d'avoir un fichier référencé deux fois, mais le nombre de références est 1
Il s'agit d'une technique d'implémentation spécifique. Il y en a d'autres.
Il se trouve que ext2 sous Linux (à partir du noyau 3.16) utilise cette technique particulière. Cependant, cela n'implique pas que le contenu du disque passe par la séquence [ancien emplacement] → [les deux emplacements] → [nouvel emplacement], car les deux opérations (ajouter une nouvelle entrée, supprimer l'ancienne entrée) ne sont pas atomiques non plus au niveau matériel. : il est possible que l'un d'eux soit interrompu, laissant le système de fichiers dans un état incohérent. (Espérons que fsck le réparera.) De plus, la couche de bloc peut réorganiser les écritures, de sorte que la première moitié pourrait être validée sur le disque juste avant le crash et que la seconde moitié n'aurait alors pas été effectuée.
Le nombre de références ne sera jamais observé comme étant différent de 1 tant que le système ne plante pas (voir ci-dessus) mais cette garantie ne s'étend pas à un crash système.
il efface d'abord le pointeur, puis copie le pointeur de sorte que l'incohérence est que le fichier a la référence 0
Encore une fois, cela fait référence à une technique de mise en œuvre particulière. Un fichier suspendu ne peut pas être observé si le système ne tombe pas en panne, mais c'est une conséquence possible d'un plantage du système, au moins dans certaines configurations.
Selon un article de blog d'Alexander Larsson , ext2 ne donne aucune garantie de cohérence en cas de plantage du système, mais ext3 le fait dans le data=ordered
mode. (Notez que ce billet de blog ne concerne pas rename
lui-même, mais la combinaison de l'écriture dans un fichier et de l'appel rename
à ce fichier.)
Theodore Ts'o, l'auteur principal des systèmes de fichiers ext2, ext3 et ext4, a écrit un article de blog sur le même sujet . Ce billet de blog traite de l' atomicité (en ce qui concerne l'environnement logiciel uniquement) et de la durabilité (qui est l'atomicité en ce qui concerne les plantages plus une garantie d'engagement, c'est-à-dire en sachant que l'opération a été effectuée). Malheureusement, je ne trouve pas d'informations sur l'atomicité en ce qui concerne les accidents seuls. Cependant, les garanties de durabilité données pour ext4 exigent qu'il rename
soit atomique. La documentation du noyau pour ext4 indique que ext4 avec l' auto_da_alloc
option (qui est la valeur par défaut dans les noyaux modernes), ainsi que ext4, fournit une garantie de durabilité pour un write
suivi d'unrename
, ce qui implique qu'il rename
est atomique en ce qui concerne les pannes matérielles.
Pour Btrfs, un rename
qui écrase un fichier existant est garanti atomique en ce qui concerne les plantages, mais un rename
qui n'écrase pas un fichier peut entraîner qu'aucun fichier ou les deux fichiers n'existent.
En résumé, la réponse à votre question est que non seulement le déplacement d'un fichier n'est pas atomique en ce qui concerne les plantages sur ext2, mais il n'est même pas garanti de laisser le fichier dans un état cohérent (bien que les échecs qui fsck
ne peuvent pas être réparés soient rares) - à peu près rien n'est, c'est pourquoi de meilleurs systèmes de fichiers ont été inventés. Ext3, ext4 et btrfs fournissent des garanties limitées.
rename
c'est atomique, mais btrfs ne le fait pas selon le wiki (voir ma réponse). Il est également possible de garantir l'atomicité sans journal (je ne connais pas d'exemples sous Linux mais il peut y en avoir). Avez-vous des informations fiables sur ext2?