J'avais l'habitude de penser que les modifications de fichier sont enregistrées directement sur le disque, c'est-à-dire dès que je ferme le fichier et décide de cliquer / sélectionner de sauvegarder. Cependant, lors d'une conversation récente, un de mes amis m'a dit que ce n'est généralement pas vrai. le système d'exploitation (nous parlons en particulier des systèmes Linux) conserve les modifications en mémoire et dispose d'un démon qui écrit le contenu de la mémoire sur le disque.

Il a même donné l'exemple des lecteurs flash externes: ceux-ci sont montés dans le système (copiés en mémoire) et parfois des pertes de données surviennent car le démon n'a pas encore enregistré le contenu dans la mémoire flash; c'est pourquoi nous démontons les lecteurs flash.

Je ne connais pas le fonctionnement des systèmes d'exploitation et je ne sais donc absolument pas si cela est vrai ni dans quelles circonstances. Ma question principale est la suivante: cela se produit-il comme cela est décrit dans les systèmes Linux / Unix (et peut-être d'autres systèmes d'exploitation)? Par exemple, cela signifie-t-il que si j'éteins l'ordinateur immédiatement après avoir édité et enregistré un fichier, mes modifications seront probablement perdues? Peut-être que cela dépend du type de disque - disques durs traditionnels par rapport aux disques à l'état solide?

La question concerne spécifiquement les systèmes de fichiers dotés d'un disque pour stocker les informations, même si toute clarification ou comparaison est bien reçue.

si j'éteins l'ordinateur immédiatement après avoir édité et enregistré un fichier, mes modifications seront probablement perdues?

Ils pourraient être. Je ne dirais pas "très probablement", mais la probabilité dépend de beaucoup de choses.

Un moyen simple d’augmenter les performances des écritures de fichiers consiste, pour le système d’exploitation, à simplement mettre en cache les données, à indiquer l’application de l’écriture, puis à effectuer l’écriture plus tard. Ceci est particulièrement utile en cas d'activité simultanée sur le disque: le système d'exploitation peut hiérarchiser les lectures et effectuer les écritures plus tard. Cela peut également supprimer complètement le besoin d'une écriture réelle, par exemple dans le cas où un fichier temporaire est supprimé rapidement par la suite.

Le problème de la mise en cache est plus prononcé si le stockage est lent. La copie de fichiers d'un SSD rapide sur une clé USB lente impliquera probablement beaucoup de cache en écriture, car la clé USB ne peut tout simplement pas suivre. Mais votre cpcommande revient plus rapidement, vous pouvez donc continuer à travailler, voire même à éditer les fichiers que vous venez de copier.

Bien sûr, la mise en cache de ce type présente l'inconvénient que vous remarquez: certaines données risquent d'être perdues avant même d'être enregistrées. L'utilisateur sera fâché si son éditeur lui a dit que l'écriture avait réussi, mais que le fichier n'était pas réellement sur le disque. C'est pourquoi il y a l' fsync()appel système , qui est censé être renvoyé uniquement après que le fichier a réellement atteint le disque. Votre éditeur peut l'utiliser pour s'assurer que les données sont correctes avant de signaler à l'utilisateur que l'écriture a réussi.

J'ai dit, "est supposé", car le lecteur lui-même pourrait raconter les mêmes mensonges au système d'exploitation et dire que l'écriture est terminée, alors que le fichier n'existe réellement que dans un cache d'écriture volatile dans le lecteur. Selon le lecteur, il pourrait ne pas être possible de contourner cela.

En outre fsync(), il existe également les appels système sync()et syncfs()qui demandent au système de s’assurer que toutes les écritures au niveau du système ou toutes les écritures sur un système de fichiers particulier ont atteint le disque. L'utilitaire syncpeut être utilisé pour appeler ceux-ci.

Ensuite, il y a aussi l' O_DIRECTindicateur toopen() , qui est censé "essayer de minimiser les effets de cache des E / S vers et depuis ce fichier". La suppression de la mise en cache réduit les performances. Elle est donc principalement utilisée par les applications (bases de données) qui effectuent leur propre mise en cache et souhaitent en prendre le contrôle. (ce O_DIRECTn’est pas sans problèmes, les commentaires à ce sujet dans la page de manuel sont quelque peu amusants.)

Ce qui se passe lors d’une mise hors tension dépend également du système de fichiers. Ce ne sont pas uniquement les données de fichiers qui devraient vous préoccuper, mais également les métadonnées du système de fichiers. Avoir les données du fichier sur le disque n'est pas d'une grande utilité si vous ne le trouvez pas. L'extension d'un fichier à une taille plus grande nécessitera l'allocation de nouveaux blocs de données, qui devront être marqués quelque part.

La manière dont un système de fichiers traite les modifications de métadonnées et l'ordre des écritures de métadonnées et de données varie beaucoup. Par exemple, avec ext4, si vous définissez l'indicateur de montage data=journal, toutes les écritures - même les écritures de données - passent par le journal et devraient être plutôt sûres. Cela signifie également qu'ils sont écrits deux fois, ce qui diminue les performances. Les options par défaut essaient de classer les écritures de sorte que les données se trouvent sur le disque avant la mise à jour des métadonnées. D'autres options ou d'autres systèmes de fichiers peuvent être meilleurs ou pires; Je ne vais même pas essayer une étude approfondie.

En pratique, sur un système faiblement chargé, le fichier doit toucher le disque en quelques secondes. Si vous utilisez du stockage amovible, démontez le système de fichiers avant d'extraire le support pour vous assurer que les données sont bien envoyées sur le lecteur et qu'il n'y a aucune autre activité. (Ou demandez à votre environnement graphique de le faire pour vous.)

Il y a un très moyen simple de prouver qu'il ne peut pas être vrai que les modifications de fichiers sont toujours enregistrés directement sur le disque, à savoir le fait qu'il ya des systèmes de fichiers qui ne sont pas soutenus par un disque en premier lieu . Si un système de fichiers ne possède un disque en premier lieu, il ne peut peut - être écrire les modifications sur le disque, jamais .

Certains exemples sont:

• tmpfs, un système de fichiers qui n'existe que dans la RAM (ou plus précisément dans le cache)
• ramfs, un système de fichiers qui n'existe que dans la RAM
• tout système de fichiers réseau (NFS, CIFS / SMB, AFS, AFP,…)
• tout système de fichiers virtuel ( sysfs, procfs, devfs, shmfs, ...)

Mais même pour les systèmes de fichiers sauvegardés sur disque, cela n’est généralement pas vrai. La page Comment corrompre une base de données SQLite contient un chapitre intitulé Echec de la synchronisation qui décrit de nombreuses manières différentes dont les écritures (dans ce cas, les validations dans une base de données SQLite) peuvent ne pas arriver sur le disque. SQLite propose également un livre blanc expliquant les nombreux obstacles à franchir pour garantir Atomic Commit In SQLite . (Notez qu'Atomic Write est un problème beaucoup plus difficile que d' écrire , mais bien sûr, l'écriture sur disque est un sous-problème d'écriture atomique, et vous pouvez en apprendre beaucoup sur ce problème également dans cet article.) Cet article a une section sur les choses qui peuvent aller mal qui comprend une sous-section surLes disques incomplets qui donnent des exemples de subtilités subtiles susceptibles d'empêcher une écriture d'atteindre le disque (par exemple, le contrôleur de disque dur signalant qu'il a écrit sur le disque alors que ce n'est pas le cas - oui, il existe des fabricants de disques durs qui le font, et cela pourrait même être légal selon la spécification ATA, car il est libellé de manière ambiguë à cet égard).

Il est vrai que la plupart des systèmes d'exploitation, y compris Unix, Linux et Windows, utilisent un cache en écriture pour accélérer les opérations. Cela signifie qu’éteindre un ordinateur sans l’éteindre est une mauvaise idée et peut entraîner une perte de données. Il en va de même si vous supprimez un stockage USB avant qu'il ne soit prêt à être supprimé.

La plupart des systèmes offrent également la possibilité de rendre les écritures synchrones. Cela signifie que les données seront sur disque avant qu'une application reçoive une confirmation de réussite, au prix d'un ralentissement.

En bref, il y a une raison pour laquelle vous devriez éteindre correctement votre ordinateur et préparer correctement le stockage USB en vue de son retrait.

1. Stockage basé sur Flash

Cela dépend-il du type de disque (disques durs traditionnels par rapport aux disques à semi-conducteurs) ou de toute autre variable dont je n'ai peut-être pas connaissance? Cela se produit-il (s'il se produit) uniquement sous Linux ou est-ce présent dans d'autres systèmes d'exploitation?

Lorsque vous avez le choix, vous ne devez pas permettre à un stockage flash de perdre de l'énergie sans un arrêt complet.

Sur un stockage peu coûteux, comme les cartes SD, vous pouvez vous attendre à perdre des blocs d'effacement entiers (plusieurs fois plus grand que 4 Ko), ainsi que des données pouvant appartenir à des fichiers différents ou à des structures essentielles du système de fichiers.

Certains SSD coûteux peuvent prétendre offrir de meilleures garanties en cas de panne de courant. Cependant, des tests effectués par des tiers suggèrent que de nombreux disques SSD coûteux ne le font pas. La couche qui remappe les blocs pour "l'usure de nivellement" est complexe et propriétaire. Les échecs possibles incluent la perte de toutes les données sur le lecteur.

En appliquant notre cadre de test, nous testons 17 disques SSD de six fournisseurs différents en utilisant plus de trois mille cycles d’injection de pannes au total. Nos résultats expérimentaux révèlent que 14 des 17 périphériques SSD testés présentent des comportements de défaillance surprenants, y compris la corruption de bits, les écritures abrégées, les écritures non sérialisables, la corruption de métadonnées et la défaillance totale du périphérique.

2017: https://dl.acm.org/citation.cfm?id=2992782&preflayout=flat

2013: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf?wptouch_preview_theme=enabled

2. Lecteurs de disque dur en rotation

Les disques durs rotatifs ont des caractéristiques différentes. Pour des raisons de sécurité et de simplicité, je recommande de supposer qu’ils ont la même incertitude pratique que le stockage flash.

Sauf si vous avez des preuves spécifiques, ce que vous n'avez manifestement pas. Je n'ai pas de chiffres comparatifs pour les disques durs.

Un disque dur peut laisser un secteur incomplètement écrit avec une mauvaise somme de contrôle, ce qui nous donnera un échec de lecture intéressant ultérieurement. De manière générale, ce mode de défaillance des disques durs est tout à fait attendu; Les systèmes de fichiers Linux natifs sont conçus dans cet esprit. Ils ont pour objectif de préserver le contrat de fsync()face à ce type de panne d'alimentation. (Nous aimerions vraiment que cela soit garanti sur les SSD).

Cependant, je ne suis pas sûr que les systèmes de fichiers Linux y parviennent dans tous les cas, ni même si cela est possible.

Le prochain démarrage après ce type d'erreur peut nécessiter une réparation du système de fichiers. Ceci étant Linux, il est possible que la réparation du système de fichiers pose des questions que vous ne comprenez pas, où vous pouvez seulement appuyer sur Y et espérer qu’elles se régleront toutes seules.

2.1 Si vous ne connaissez pas le contrat fsync ()

Le contrat fsync () est une source de bonnes et de mauvaises nouvelles. Vous devez d'abord comprendre la bonne nouvelle.

Bonne nouvelle: il fsync()est bien documenté que la manière correcte d'écrire des données de fichier, par exemple lorsque vous cliquez sur "enregistrer". Et il est généralement admis que, par exemple, les éditeurs de texte doivent remplacer les fichiers existants de manière atomique rename(). Cela a pour but de vous assurer que vous conservez toujours l'ancien fichier ou récupérez le nouveau fichier (qui était fsync()édité avant le changement de nom). Vous ne voulez pas vous retrouver avec une version à moitié écrite du nouveau fichier.

Mauvaise nouvelle: pendant de nombreuses années, appeler fsync () sur le système de fichiers Linux le plus répandu risquait de mettre tout le système en attente pendant des dizaines de secondes. Étant donné que les applications ne peuvent rien y faire, il était très courant d’utiliser de manière optimiste rename () sans fsync (), qui semblait relativement fiable sur ce système de fichiers.

Par conséquent, il existe des applications qui n'utilisent pas fsync () correctement.

La prochaine version de ce système de fichiers évitait généralement le blocage de fsync () - au moment même où il commençait à compter sur l'utilisation correcte de fsync ().

C'est vraiment pas terrible. La compréhension de cette histoire n’est probablement pas aidée par le ton dédaigneux et l’invective qui ont été utilisés par de nombreux développeurs du noyau en conflit.

La résolution actuelle est que le système de fichiers Linux le plus populaire prend en charge par défaut le modèle rename () sans nécessiter fsync ()implémente la "compatibilité bug-à-bug" avec la version précédente. Cela peut être désactivé avec l'option de montage noauto_da_alloc.

Ce n'est pas une protection complète. Fondamentalement, il efface l'IO en attente au moment de renommer (), mais n'attend pas que l'IO se termine avant de renommer. C'est bien mieux qu'une fenêtre de danger de 60 secondes par exemple! Voir aussi la réponse à la question Quels systèmes de fichiers ont besoin de fsync () pour la sécurité contre les collisions lors du remplacement d'un fichier existant par rename ()?

Certains systèmes de fichiers moins populaires ne fournissent pas de protection. XFS refuse de le faire. Et UBIFS ne l’a pas implémentée non plus, elle pourrait apparemment être acceptée, mais elle nécessite beaucoup de travail pour la rendre possible. La même page indique qu'UBIFS présente plusieurs autres problèmes "TODO" concernant l'intégrité des données, y compris en cas de coupure de courant. UBIFS est un système de fichiers utilisé directement sur un stockage flash. J'imagine que certaines des difficultés mentionnées par UBIFS concernant le stockage flash pourraient être pertinentes pour les bogues SSD.

Sur un système peu chargé, le noyau laissera les données de fichier nouvellement écrites dans le cache de pages pendant environ 30 secondes après write(), avant de les transférer sur le disque, afin d’optimiser le cas où elles seront bientôt supprimées ou modifiées.

La valeur par dirty_expire_centisecsdéfaut de Linux est 3 000 (30 secondes) et contrôle le temps qui s'écoule avant "l'expiration" des données récemment écrites. (Voir https://lwn.net/Articles/322823/ ).

Voir https://www.kernel.org/doc/Documentation/sysctl/vm.txt pour plus de paramètres ajustables, et Google pour beaucoup plus. (par exemple google sur dirty_writeback_centisecs).

La valeur par défaut de Linux /proc/sys/vm/dirty_writeback_centisecsest 500 (5 secondes) et PowerTop recommande de le définir sur 1500 (15 secondes) pour réduire la consommation d'énergie.

L'écriture différée donne également au noyau le temps de voir la taille d'un fichier avant de commencer à l'écrire sur le disque. Les systèmes de fichiers avec allocation différée (comme XFS et probablement d’autres de nos jours) ne choisissent même pas où placer sur le disque les données d’un fichier récemment écrit jusqu’à leur nécessité, séparément de l’allocation d’espace pour l’inode lui-même. Cela réduit la fragmentation en leur permettant d'éviter de placer le début d'un fichier volumineux dans un espace de 1 mégaoctet par rapport aux autres fichiers, par exemple.

Si de nombreuses données sont en cours d'écriture, l'écriture sur le disque peut être déclenchée par un seuil indiquant le nombre de données incorrectes (non encore synchronisées sur le disque) pouvant figurer dans le cache de page.

Cependant, si vous ne faites pas grand chose d'autre, le voyant d'activité de votre disque dur ne s'allumera pas avant 5 (ou 15) secondes après une sauvegarde sur un petit fichier.

Si votre éditeur a utilisé fsync()après l'écriture du fichier, le noyau l'écrira sur le disque sans délai. (Et fsyncne reviendra que lorsque les données auront été envoyées sur le disque).

La mise en cache en écriture sur le disque peut également être une chose, mais les disques essaient normalement de valider leur cache en écriture dans un stockage permanent dès que possible, contrairement aux algorithmes de cache de page de Linux. Les caches d’écriture sur disque sont davantage un tampon de magasin pour absorber de petites rafales d’écritures, mais aussi peut-être aussi pour retarder les écritures en faveur des lectures, et donner aux micrologiciels la place nécessaire pour optimiser un modèle de recherche (par exemple, faire deux écritures ou lectures à la place , puis cherchant loin, puis cherchant en arrière.)

Sur un disque (magnétique) en rotation, il se peut que vous attendiez quelques délais de recherche de 7 à 10 ms avant que les données d'une commande d'écriture SATA ne soient réellement protégées de toute mise hors tension, s'il y avait des lectures / écritures en attente avant votre écriture. (D'autres réponses à cette question donnent davantage de détails sur les caches d'écriture sur disque et sur les barrières que les FS journalisés peuvent utiliser pour éviter la corruption.)