Le système de fichiers peut-il devenir incohérent s'il est interrompu lors du déplacement d'un fichier?

J'ai deux dossiers sur la même partition (EXT2) Si moi mv folder1/file folder2et une interruption (par exemple une panne de courant) le système de fichiers pourrait-il finir par être incohérent?

L' mvopération n'est-elle pas atomique?

Mise à jour: Jusqu'à présent sur IRC, j'ai eu les perspectives suivantes:

1. c'est atomique donc les incohérences ne peuvent pas arriver
2. 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
3. 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

Quelqu'un peut-il clarifier?

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=orderedmode. (Notez que ce billet de blog ne concerne pas renamelui-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 renamesoit atomique. La documentation du noyau pour ext4 indique que ext4 avec l' auto_da_allocoption (qui est la valeur par défaut dans les noyaux modernes), ainsi que ext4, fournit une garantie de durabilité pour un writesuivi d'unrename, ce qui implique qu'il renameest atomique en ce qui concerne les pannes matérielles.

Pour Btrfs, un renamequi écrase un fichier existant est garanti atomique en ce qui concerne les plantages, mais un renamequi 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 fsckne 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.

L'opération de changement de nom est très rapide sur n'importe quel système de fichiers, il est donc peu probable qu'elle soit interrompue, mais sur un système de fichiers classique, elle peut certainement être interrompue - si elle crée d'abord le lien de destination, elle pourrait laisser deux liens sur un fichier - ce qui est légal, mais le fichier pense qu'il n'en a qu'un, ce qui pourrait causer des problèmes si l'un est supprimé plus tard. En revanche, s'il supprime d'abord le lien source, le fichier pourrait être perdu. L'exécution de fsck détectera et corrigera généralement l'une ou l'autre condition, bien que si le fichier est perdu, il sera placé dans un répertoire "lost + found" avec un nom arbitraire plutôt qu'à l'emplacement souhaité - et s'il a deux liens, le nombre de liens sera simplement être mis à jour, donc le fichier existera à deux endroits si le système de fichiers le prend en charge.

Si vous avez besoin d'un système de fichiers pour être robuste face aux pannes de courant, vous devez utiliser un système de fichiers de journalisation , tel que NTFS, EXT3 ou XFS. La plupart des systèmes modernes utilisent par défaut un système de fichiers de journalisation, mais vous devez savoir que FAT n'est pas un système de fichiers de journalisation si vous l'utilisez pour des lecteurs externes.

Un système de fichiers de journalisation utilise un système à "double entrée" - il écrit dans le fichier journal le fait qu'il a l'intention de le déplacer, puis effectue le déplacement. Lorsque le système de fichiers est vérifié au démarrage, s'il a été interrompu, il remarquera que le déplacement n'était pas terminé et le refait ensuite.

Il existe deux types de systèmes de fichiers de journalisation: la journalisation des métadonnées et la journalisation complète. La journalisation des métadonnées signifie qu'elle ne garde pas la trace des modifications apportées au contenu des fichiers dans le système de journal (ainsi, vous pourriez finir par perdre le contenu si vous écrivez dans un fichier), mais elle gardera toujours la trace des informations importantes sur le système de fichiers telles que le contenu du répertoire , propriétés des fichiers, etc.

Lorsque les gens disent que l'opération de renommage est atomique, cela signifie qu'elle ne peut pas être observée à mi-transition par un autre processus sur le système, et elle ne peut pas être laissée à moitié terminée, par exemple en interrompant la mvcommande elle-même avec ^C. Le processus physique d'écriture dans chaque répertoire, dont l'espace de stockage peut se trouver dans des emplacements très différents sur le disque, ne peut pas être une opération vraiment atomique au niveau matériel.

Pour être complet, je noterai que certaines opérations d'E / S accessoires sont également associées à un changement de nom en plus de créer le nouveau lien dans le répertoire de destination et de le supprimer dans l'ancien - mise à jour du mtime des deux répertoires, étendant éventuellement le taille d'allocation du répertoire de destination, modification du ..lien et du nombre de liens des répertoires parents si le fichier est un répertoire. En outre, je ne suis pas sûr si le temps du fichier lui-même est affecté.

Cette question a été posée d'une manière légèrement différente sur Super User. La page Wikipedia sur la mvcommande l' explique aussi assez bien:

Le déplacement de fichiers dans le même système de fichiers est généralement mis en œuvre différemment de la copie du fichier, puis de la suppression de l'original. Sur les plates-formes qui ne prennent pas en charge le renommage syscall, un nouveau lien est ajouté au nouveau répertoire et l'original est supprimé. Les données du fichier ne sont pas accessibles.

Linux a renommé syscall et renommera donc le fichier comme une opération atomique, c'est-à-dire non interruptible. Donc non, le système de fichiers ne peut pas devenir incohérent dans la situation que vous avez décrite.