Qual è l'intera funzione e l'effetto di "Disattiva il flush del buffer della cache di scrittura di Windows sul dispositivo"

In Windows 7, usando Gestione dispositivi, facendo apparire le proprietà di un disco e andando alla scheda Politiche, ci sono 2 elementi switch. La cache di scrittura, di cui questa domanda non si tratta.

e

[X] Disattiva il flush del buffer della cache di scrittura di Windows sul dispositivo <--- solo questo!

Microsoft mette un disclaimer nella scheda per quell'elemento. "Per prevenire la perdita di dati, non selezionare questa casella di controllo a meno che il dispositivo non disponga di un alimentatore separato che consenta al dispositivo di svuotare il buffer in caso di interruzione dell'alimentazione."

In termini semplici, cosa cambia per la scrittura, il salvataggio e la copia dei file?

1. Modifica delle azioni di scrittura per i programmi paranoici: (fatto o finzione)
Cambia il modo in cui i flush di scrittura funzionano per un programma che impone lo svuotamento della cache? Alcuni programmi sono molto intenzionati a terminare la scrittura, senza speculazioni, sono in grado di continuare la loro scrittura protettiva o questo cambiamento cambia anche per quei programmi?

2. Tipi di programmi effettuati:
quali sono i tipi di azioni / programmi che verrebbero o meno modificati dal cambiamento? Tipo, alcuni programmi in streaming, alcuni eseguono rapide scritture, altri sono continui, altri sono protettivi (o qualsiasi altro tipo che potresti definire in termini semplici).

3. Hai visto qualcosa o addirittura un benchmark:
se l'impostazione è attiva, quali sono le modifiche osservabili nella scrittura? Eventuali esempi vaghi di un cambiamento osservato nel comportamento. o osservato alcun cambiamento nel comportamento?

4. Qual è il ritardo o il ritardo:
sappiamo che la maggior parte di queste azioni sono molto veloci sulla maggior parte dei computer. I dati verranno eventualmente scritti. Rispetto alla velocità dell'azionamento, la quantità di tempo è significativa?

Ai fini della mia domanda, il rischio che esiste non è una delle domande, se si desidera coprirlo, non si frappone.

Ciò che significa "Scrivi svuotamento buffer cache" è quasi un duplice, ma il collegamento è per un sistema operativo diverso. Sebbene A abbia alcune informazioni, anche il termine usato nel link non è lo stesso. Inoltre non risponde alle cose più significative che un utente vorrebbe sapere, che ho cercato di delineare qui.

1. La tua affermazione nella prima domanda è finzione. API di Windows chiama come sarà ancora garantire che i dati ottiene tutta la via d'uscita per i supporti fisici, anche con scrittura buffer di lavaggio disattivata. Quindi, i programmi che sono "sicuri" e sanno cosa stanno facendo andranno bene. Chiamate come in .NET, ecc. Alla fine chiamano questa API.FlushFileBuffers() FileStream.Flush()

2. I programmi che eseguono molti I / O su disco senza chiamare FlushFileBuffers()direttamente, o qualsiasi API di supporto che alla fine lo chiama, vedrebbero aumentare le prestazioni più evidenti. Ad esempio, se si eseguisse un I / O non essenziale dove va bene se i dati vengono persi, come BOINC (se si perde si scarica nuovamente il file o si tenta di ricalcolare i calcoli), è possibile evitare di chiamare FlushFileBuffers()e chiama semplicemente un'API come WriteFile(): i dati verranno bufferizzati per essere scritti, ma in realtà non verranno scritti per un periodo potenzialmente lungo, ad esempio quando il descrittore di file viene chiuso o quando il programma esce. Sfortunatamente è anche possibile che se il sistema si arresta in modo anomalo (come un BSOD), tutti i dati vengono persi, quindi è davvero importanteche se avete a che fare con qualsiasi tipo di dati importanti / non sostituibili che non fai chiamata FlushFileBuffers(), se buffer di vampate di calore è abilitato o meno! Altrimenti un semplice bug del driver (ad esempio nel tuo driver grafico) potrebbe farti perdere molti dati.

3. Non riesci a trovare alcun benchmark, ma lo noterai di più con i programmi che si adattano alla descrizione nel secondo elemento sopra.

4. La sincronizzazione dei dati su disco non è in realtà così rapida, specialmente se eseguita frequentemente in un ciclo stretto. Per impostazione predefinita, se ricordo correttamente dalla lettura dei libri di Windows Internals, NTFS di default sincronizza tutti i buffer del filesystem sporco su disco ogni 5 secondi . Questo è apparentemente un discreto compromesso tra stabilità e prestazioni. Il problema con la sincronizzazione frequente dei dati è che fa sì che il disco rigido esegua molte ricerche e scritture.

Considera il seguente pseudocodice:

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()

Con automatico a 5 secondo tampone di lavaggio su :

• Le scritture che si verificano sulle righe 2, 5 e 7 si verificano nella RAM e il disco non si sposta, fino a quando non sono trascorsi 5 secondi dalla prima scrittura, quindi i dati più recenti (dalla riga 7) vengono scritti nel blocco (1) e il vengono scritti solo i dati scritti nel blocco (2).
• Le scritture che si verificano sulle righe 10 e 13, che sovrascrivono i dati nei blocchi (1) e (2), devono essere nuovamente scritte sul disco
• Quindi il numero totale di volte che il blocco (1) è stato scritto nella RAM è 3, e su disco , 2. Il numero totale di volte che quel blocco (2) è stato scritto sulla RAM è 2, e su disco , 2.

Con lo svuotamento automatico del buffer di 5 secondi disattivato (l'effetto della casella di controllo nella domanda):

• Le scritture che si verificano sulle righe 2, 5, 7, 10 e 13 si verificano nella RAM e il disco non si sposta, fino a quando non viene eseguita la riga 14 e quindi i dati più recenti (dalle righe 10 e 13) vengono scritti in blocchi (1) e (2). I vecchi dati delle linee 2, 5 e 7 non colpiscono mai il disco rigido!

Considerando che un sistema occupato può sperimentare da centinaia a decine di migliaia di scritture su file al secondo, questo è ottimo per le prestazioni, specialmente sui dischi rigidi tradizionali (è meno impressionante sugli SSD). La RAM è 20 volte più veloce dei dischi rigidi come misura generale, sebbene questo gap sia minore con gli SSD.

Il motivo per cui dicono che dovresti usare un backup della batteria è che non vuoi avere 35 minuti di dati scritti bufferizzati nella RAM che non sono scritti su disco solo perché il tuo programmatore era pigro e non ha chiamato FlushFileBuffers(), e quindi ha un'interruzione di corrente. Naturalmente, un backup della batteria non ti protegge dai bug del driver che causano un BSOD ....

A supporto della risposta di ChatBot John Cavil , ho scritto un piccolo programma di 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() `
// ...

Ed eseguilo su un disco Samsung 950pro NVMe con l'opzione "Disattiva svuotamento buffer di cache di scrittura di Windows sul dispositivo" abilitata.

Il risultato è:

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()

Quindi puoi vedere che la FlushFileBuffersrichiesta non è stata omessa dal sistema (Windows non ignora la FlushFileBufferschiamata anche se le opzioni sono abilitate).