si j'éteins l'ordinateur immédiatement après avoir modifié et enregistré un fichier, mes modifications seront probablement perdues ?
Ils pourraient être. Je ne dirais pas "le plus probable", 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, à dire (mentir) à l'application par laquelle l'écriture est passée, puis à effectuer l'écriture plus tard. Ceci est particulièrement utile s'il y a une autre activité de disque en cours en même temps :le système d'exploitation peut donner la priorité aux 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 mise en cache est plus prononcé si le stockage est lent. La copie de fichiers d'un SSD rapide vers une clé USB lente impliquera probablement beaucoup de mise en cache en écriture, car la clé USB ne peut tout simplement pas suivre. Mais votre cp La commande revient plus rapidement, vous pouvez donc continuer à travailler, voire même éditer les fichiers qui viennent d'être copiés.
Bien sûr, une telle mise en cache a l'inconvénient que vous notez, certaines données peuvent être perdues avant d'être réellement enregistrées. L'utilisateur sera vexé si son éditeur lui dit que l'écriture a réussi, mais que le fichier n'était pas réellement sur le disque. C'est pourquoi il y a le fsync() appel système, qui est censé revenir uniquement après que le fichier a effectivement 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 censé le faire", car le lecteur lui-même pourrait dire les mêmes mensonges au système d'exploitation et dire que l'écriture est terminée, alors que le fichier n'existe vraiment que dans un cache d'écriture volatile au sein du lecteur. Selon le lecteur, il n'y a peut-être pas moyen de contourner cela.
En plus de fsync() , il y a aussi les sync() et syncfs() appels système qui demandent au système de s'assurer que toutes les écritures à l'échelle du système ou toutes les écritures sur un système de fichiers particulier ont atteint le disque. L'utilitaire sync peut être utilisé pour les appeler.
Ensuite, il y a aussi le O_DIRECT indicateur à open() , 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, ce qui est principalement utilisé par les applications (bases de données) qui font leur propre mise en cache et veulent en avoir le contrôle.(O_DIRECT n'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 coupure de courant dépend également du système de fichiers. Ce ne sont pas seulement les données du fichier qui vous préoccupent, mais les métadonnées du système de fichiers. Avoir les données du fichier sur le disque n'est pas très utile si vous ne pouvez pas le trouver. Le simple fait d'étendre un fichier à une taille plus grande nécessitera d'allouer de nouveaux blocs de données, et ils doivent être marqués quelque part.
La façon dont un système de fichiers traite les changements de métadonnées et l'ordre entre les métadonnées et les écritures de données varie beaucoup. Par exemple, avec ext4 , si vous définissez l'indicateur de montage data=journal , alors 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 réduit les performances. Les options par défaut tentent d'ordonner les écritures de manière à ce que les données soient 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 n'essaierai même pas une étude approfondie.
En pratique, sur un système peu chargé, le fichier devrait arriver sur le disque en quelques secondes. Si vous avez affaire à un stockage amovible, démontez le système de fichiers avant d'extraire le support pour vous assurer que les données sont réellement envoyées au lecteur et qu'il n'y a plus d'activité. (Ou laissez votre environnement graphique le faire pour vous.)
Il y a un extrêmement moyen simple de prouver qu'il ne peut pas être vrai que les modifications de fichiers sont toujours directement enregistrées sur le disque, à savoir le fait qu'il existe des systèmes de fichiers qui ne sont pas sauvegardés par un disque en premier lieu . Si un système de fichiers n'a pas un disque en premier lieu, alors il ne peut pas écrire les modifications sur le disque, toujours .
Voici quelques exemples :
tmpfs, un système de fichiers qui n'existe que dans la RAM (ou plus précisément, dans le cache tampon)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é Échec de la synchronisation qui décrit de nombreuses manières différentes par lesquelles les écritures (dans ce cas, les validations dans une base de données SQLite) peuvent ne pas arriver sur le disque. SQLite a également un livre blanc expliquant les nombreux obstacles que vous devez franchir pour garantir Atomic Commit In SQLite . (Notez que Atomic Write est un problème beaucoup plus difficile que simplement écrire , mais bien sûr l'écriture sur disque est un sous-problème de l'écriture atomique, et vous pouvez également en apprendre beaucoup sur ce problème grâce à cet article.) Cet article a une section sur Les choses qui peuvent mal tourner qui comprend une sous-section sur les vidages de disque incomplets qui donnent quelques exemples de subtilités subtiles qui pourraient empêcher une écriture d'atteindre le disque (comme le contrôleur de disque dur signalant qu'il a écrit sur le disque alors qu'il ne l'a pas fait - oui, il y a des fabricants de disques durs qui le font, et cela pourrait même être légal selon la spécification ATA, car elle est formulée 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 ne reçoive une confirmation de réussite, au prix d'être plus lente.
En bref, il y a une raison pour laquelle vous devez éteindre correctement votre ordinateur et préparer correctement le stockage USB pour le retrait.