Quelle est la fonction et l'effet de «Désactiver le vidage du tampon de cache d'écriture Windows sur l'appareil»

Dans Windows 7, en utilisant le Gestionnaire de périphériques, en affichant les propriétés d'un disque et en accédant à l'onglet Stratégies, il y a 2 éléments de commutation. Le cache d'écriture, dont il ne s'agit pas de cette question.

et

[X] Désactiver le vidage du tampon de cache d'écriture Windows sur le périphérique <--- celui-ci uniquement!

Microsoft met une clause de non-responsabilité sur l'onglet de cet élément. "Pour éviter toute perte de données, ne cochez cette case que si l'appareil dispose d'une alimentation séparée qui lui permet de vider sa mémoire tampon en cas de coupure de courant."

En termes simples, qu'est-ce que cela change pour l'écriture de fichiers, l'enregistrement de fichiers, la copie de fichiers?

1. Changer les actions d'écriture pour les programmes paranoïaques: (réalité ou fiction)
Cela change-t-il la façon dont les vidages d'écriture fonctionnent pour un programme qui force un vidage du cache à se produire? Certains programmes sont très déterminés à terminer l'écriture, sans spéculer, ces programmes sont-ils capables de poursuivre leur écriture protectrice, ou cela change-t-il également pour ces programmes?

2. Types de programmes effectués:
Quels sont les types d'actions / programmes qui seraient ou ne seraient pas affectés par le changement? Tapez, certains flux de programmes, certains font des écritures rapides, certains sont continus, certains sont protecteurs (ou tout autre type que vous pourriez définir en termes simples).

3. Avez-vous vu quelque chose, ou même une référence:
si le réglage est activé, quels sont les changements observables par écrit? Tout exemple lâche d'un changement de comportement observé. ou observé aucun changement de comportement?

4. Quel est le retard ou le retard:
Nous savons que la plupart de ces actions sont très rapides sur la plupart des ordinateurs, les données seront éventuellement écrites. Par rapport à la vitesse du variateur, la durée est-elle significative?

Aux fins de ma question, le risque qui existe ne fait pas partie des questions, si vous voulez le couvrir, il ne gênerait pas.

Qu'est-ce que cela signifie "écrire le vidage du tampon de cache" est presque une dupe, mais le lien est pour un système d'exploitation différent. Bien que le A contienne des informations, même le terme utilisé dans le lien n'est pas le même. Il ne répond pas non plus aux choses les plus importantes qu'un utilisateur voudrait savoir, que j'ai essayé de décrire ici.

1. Votre affirmation dans la première question est une fiction. Appelle l' API Windows, comme s'assurer encore que les données obtient tout le chemin vers les médias physiques, même avec écriture tampon de rinçage désactivé. Ainsi, les programmes qui sont «sûrs» et savent ce qu'ils font vont très bien. Des appels comme dans .NET, etc. finissent par appeler cette API.FlushFileBuffers() FileStream.Flush()

2. Les programmes qui font beaucoup d'E / S disque sans appeler FlushFileBuffers()directement, ou toute API d'assistance qui l'appelle éventuellement, verraient l'augmentation des performances la plus notable. Par exemple, si vous exécutiez des E / S non essentielles où tout va bien si des données sont perdues, comme BOINC (si elles se perdent, vous téléchargez à nouveau le fichier ou essayez de recalculer les calculs), vous pourriez éviter d'appeler FlushFileBuffers(), et appelez simplement une API comme WriteFile()- les données seront mises en mémoire tampon pour être écrites, mais elles ne seront pas écrites pendant longtemps, par exemple lorsque le descripteur de fichier est fermé ou lorsque le programme se ferme. Malheureusement, il est également possible que si le système plante (comme un BSOD), toutes les données soient perdues, il est donc très importantque si vous faites affaire avec tout type de données précieuses / non remplaçables que vous ne faites appel FlushFileBuffers(), si le rinçage de la mémoire tampon est activé ou non! Sinon, un simple bug de pilote (par exemple dans votre pilote graphique) pourrait vous faire perdre beaucoup de données.

3. Impossible de trouver des repères, mais vous le remarquerez davantage avec les programmes qui correspondent à la description du deuxième élément ci-dessus.

4. La synchronisation des données sur le disque n'est pas vraiment aussi rapide, surtout si elle est effectuée fréquemment dans une boucle étroite. Par défaut, si je me souviens bien de la lecture des livres Windows Internals, NTFS par défaut synchronise tous les tampons de système de fichiers sales sur le disque toutes les 5 secondes . Il s'agit apparemment d'un compromis décent entre stabilité et performances. Le problème avec la synchronisation fréquente des données est qu'elle oblige le disque dur à effectuer de nombreuses recherches et écritures.

Considérez le pseudocode suivant:

1: seek to a certain block (1)
2: write a couple megabytes of data into blocks starting at (1)
3: wait 2 seconds
4: seek to another block (2)
5: write some more megabytes of data into blocks starting at (2)
6: seek back to block (1)
7: write some more megabytes of data into blocks starting at (1)
8: wait 10 minutes
9: seek to block (1)
10: write some megabytes of data into blocks starting at (1)
11: wait 5 seconds
12: seek to block (2)
13: write some megabytes of data into blocks starting at (2)
14: explicit call to FlushFileBuffers()

Avec automatique 5 secondes de rinçage tampon sur :

• Les écritures se produisant sur les lignes 2, 5 et 7 se produisent dans la RAM et le disque ne bouge pas, jusqu'à ce que 5 secondes se soient écoulées depuis la première écriture, puis les dernières données (de la ligne 7) sont écrites dans le bloc (1) et le seules les données écrites dans le bloc (2) sont écrites.
• Les écritures se produisant sur les lignes 10 et 13, qui écrasent les données dans les blocs (1) et (2), doivent à nouveau être écrites sur le disque
• Ainsi, le nombre total de fois que le bloc (1) a été écrit sur la RAM est de 3 et sur le disque , 2. Le nombre total de fois que le bloc (2) a été écrit sur la RAM est de 2 et sur le disque , 2.

Avec automatique à 5 second tampon de rinçage hors (l'effet de la case à cocher dans votre question):

• Les écritures se produisant sur les lignes 2, 5, 7, 10 et 13 se produisent dans la RAM et le disque ne bouge pas, jusqu'à ce que la ligne 14 soit exécutée, puis les dernières données (des lignes 10 et 13) soient écrites dans des blocs (1) et (2). Les anciennes données des lignes 2, 5 et 7 n'atteignent jamais le disque dur!

Étant donné qu'un système occupé peut subir entre des centaines et des dizaines de milliers d'écritures sur des fichiers par seconde, c'est excellent pour les performances, en particulier sur les disques durs traditionnels (c'est moins impressionnant sur les SSD). La RAM est 20 fois plus rapide que les disques durs en général, bien que cet écart soit moindre avec les SSD.

La raison pour laquelle ils disent que vous devriez utiliser une sauvegarde sur batterie est que vous ne voulez pas avoir 35 minutes de données écrites en mémoire tampon qui ne sont pas écrites sur le disque simplement parce que votre programmeur était paresseux et n'a pas appelé FlushFileBuffers(), puis une panne de courant. Bien sûr, une batterie de secours ne vous protège pas contre les bugs du pilote qui provoquent un BSOD ....

À l'appui de la réponse de ChatBot John Cavil , j'ai écrit un petit programme de test:

// ...
byteEx btTest;
btTest.resize(1024*1024, 0xff); // 1MB data

CSysFile sfTest(byT("test.bin"));

swTest.Start(); // Begin timing by call `QueryPerformanceCounter` API
for (UINT i=0; i<10000; ++i) // Write 1MB data for 10000 times
{
    sfTest.SeekBegin();
    sfTest.Write(btTest); // Call `WriteFile` API 
//  sfTest.Flush();       // Call `FlushFileBuffers` API
}
swTest.Stop(); // Calculate the time-consuming start from `swTest.Start() `
// ...

Et exécutez-le sur un disque Samsung 950pro NVMe avec l'option «Désactiver le vidage du tampon de cache d'écriture Windows sur l'appareil».

Le résultat est:

D:\tmp> test        // without sfTest.Flush();
00:00:00.729766     // use 0.73 seconds without FlushFileBuffers()

D:\tmp> test        // with sfTest.Flush();
00:00:06.736167     // use 6.74 seconds with FlushFileBuffers()

Ainsi, vous pouvez voir que la FlushFileBuffersdemande n'est pas omise par le système (Windows n'ignore pas l' FlushFileBuffersappel même si les options sont activées).