¿Cuál es toda la función y el efecto de "Desactivar el vaciado del búfer de caché de escritura de Windows en el dispositivo"

En Windows 7, usando el Administrador de dispositivos, mostrando las propiedades de un disco y yendo a la pestaña Políticas, hay 2 elementos de cambio. El caché de escritura, del que no se trata esta pregunta.

y

[X] Desactiva el vaciado del búfer de escritura de Windows en el dispositivo <--- ¡este solo!

Microsoft pone un descargo de responsabilidad en la pestaña de ese elemento. "Para evitar la pérdida de datos, no seleccione esta casilla de verificación a menos que el dispositivo tenga una fuente de alimentación separada que le permita descargar su búfer en caso de pérdida de energía".

En términos simples, ¿qué cambia esto para la escritura, el almacenamiento y la copia de archivos?

1. Cambio de acciones de escritura para programas paranoicos: (realidad o ficción)
¿Cambia la forma en que funcionan los vaciado de escritura para un programa que obliga a que se produzca un vaciado de caché? Algunos programas tienen mucha intención de terminar la escritura, sin especular, ¿pueden estos programas continuar con su escritura protectora, o esto también cambia para esos programas?

2. Tipos de programas efectuados:
¿Cuáles son los tipos de acciones / programas que se verían afectados o no por el cambio? Escriba, algunos programas transmiten, algunos escriben rápidamente, algunos son continuos, otros son protectores (o cualquier otro tipo que pueda definir en términos simples).

3. ¿Vio algo, o incluso un punto de referencia?
Si la configuración está activada, ¿cuáles son los cambios observables por escrito? Cualquier ejemplo suelto de un cambio observado en el comportamiento. u observado ningún cambio en el comportamiento?

4. ¿Cuál es el atraco o retraso?
Sabemos que la mayoría de estas acciones son muy rápidas en la mayoría de las computadoras. Los datos eventualmente se escribirán. En relación con la velocidad de la unidad, ¿es importante la cantidad de tiempo?

A los fines de mi pregunta, el riesgo que existe no es una de las preguntas, si desea cubrirlo, no se interpondrá en el camino.

Lo que significa "Vaciar el búfer de memoria caché de escritura" es casi un engaño de esto, pero el enlace es para un sistema operativo diferente. Aunque la A tiene alguna información, incluso el término utilizado en el enlace no es el mismo. Tampoco responde las cosas más importantes que un usuario quisiera saber, que he tratado de resumir aquí.

1. Su afirmación en la primera pregunta es ficción. Las llamadas a la API de Windows, como todavía, garantizarán que los datos lleguen a los medios físicos, incluso con el vaciado del búfer de escritura deshabilitado. Entonces, los programas que son "seguros" y saben lo que están haciendo estarán bien. Las llamadas como en .NET, etc. eventualmente llaman a esta API.FlushFileBuffers() FileStream.Flush()

2. Los programas que realizan una gran cantidad de E / S de disco sin llamar FlushFileBuffers()directamente, o cualquier API auxiliar que eventualmente lo llame, verían el aumento de rendimiento más notable. Por ejemplo, si estaba ejecutando E / S no esenciales donde está bien si se pierden datos, como BOINC (si se pierde, simplemente vuelva a descargar el archivo o intente volver a calcular los cálculos), podría evitar llamar FlushFileBuffers(), y simplemente llame a una API como WriteFile(): los datos se almacenarán en el búfer para escribirse, pero en realidad no se escribirán durante un tiempo potencialmente largo, como cuando se cierra el descriptor de archivo o cuando se cierra el programa. Desafortunadamente, también es posible que si el sistema falla (como un BSOD), todos los datos se pierden, por lo que es realmente importanteque si está tratando con algún tipo de datos valiosos / no reemplazables a los que sí llama FlushFileBuffers(), ¡ya sea que el lavado del búfer esté habilitado o no! De lo contrario, un simple error del controlador (por ejemplo, en su controlador de gráficos) podría hacer que pierda muchos datos.

3. No puedo encontrar ningún punto de referencia, pero lo notará más con los programas que se ajustan a la descripción en el segundo elemento anterior.

4. Sincronizar datos con el disco no es realmente tan rápido, especialmente si se realiza con frecuencia en un ciclo cerrado. De manera predeterminada, si recuerdo correctamente al leer los libros de Windows Internals, NTFS sincroniza de manera predeterminada todos los búferes de sistema de archivos sucios en el disco cada 5 segundos . Aparentemente, esta es una compensación decente entre estabilidad y rendimiento. El problema con la sincronización frecuente de datos es que hace que el disco duro haga muchas búsquedas y escrituras.

Considere el siguiente pseudocódigo:

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 el lavado automático del búfer de 5 segundos encendido :

• Las escrituras que ocurren en las líneas 2, 5 y 7 ocurren en la RAM y el disco no se mueve, hasta que hayan transcurrido 5 segundos desde la primera escritura, y luego los últimos datos (de la línea 7) se escriben en el bloque (1) y el solo se escriben los datos escritos en el bloque (2).
• Las escrituras que ocurren en las líneas 10 y 13, que sobrescriben los datos en los bloques (1) y (2), deben volver a escribirse en el disco
• Entonces, el número total de veces que el bloque (1) se escribió en la RAM es 3, y en el disco , 2. El número total de veces que el bloque (2) se escribió en la RAM es 2, y en el disco , 2.

Con automática de 5 segundo tampón de lavado fuera (el efecto de la casilla de verificación en su pregunta):

• Las escrituras que ocurren en las líneas 2, 5, 7, 10 y 13 ocurren en la RAM y el disco no se mueve, hasta que se ejecuta la línea 14, y luego los últimos datos (de las líneas 10 y 13) se escriben en bloques (1) y 2). ¡Los datos antiguos de las líneas 2, 5 y 7 nunca llegan al disco duro!

Teniendo en cuenta que un sistema ocupado puede experimentar entre cientos y decenas de miles de escrituras en archivos por segundo, esto es excelente para el rendimiento, especialmente en los discos duros giratorios tradicionales (es menos impresionante en los SSD). La RAM es 20 veces más rápida que los discos duros como medida general, aunque esa brecha es menor con los SSD.

La razón por la que dicen que debe usar una batería de respaldo es que no desea tener 35 minutos de datos escritos almacenados en la memoria RAM que no se escriben en el disco solo porque su programador fue flojo y no llamó FlushFileBuffers(), y luego Una falla de energía. Por supuesto, una batería de respaldo no lo protege contra los errores del controlador que causan un BSOD ...

En apoyo de la respuesta de ChatBot John Cavil , he escrito un pequeño programa de prueba:

// ...
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() `
// ...

Y ejecútelo en un disco Samsung 950pro NVMe con la opción "Desactivar el vaciado del búfer de escritura de Windows en el dispositivo" habilitado.

El resultado es:

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

Por lo tanto, puede ver que el FlushFileBufferssistema no omite la solicitud (Windows no ignora la FlushFileBuffersllamada, incluso si las opciones están habilitadas).