¿Cuánto tiempo se pueden almacenar en caché las escrituras del sistema de archivos con ext4?

Hace un tiempo, se ha debatido sobre la posibilidad de que ext4 deje los archivos vacíos después de un desmontaje inmundo, resumido bastante bien en este artículo . Básicamente, debido a la asignación retrasada, las escrituras pueden mantenerse en la caché de escritura durante mucho más tiempo que el intervalo de confirmación predeterminado del diario ext (5 segundos).

Los problemas parecen haberse solucionado en un parche que fuerza la asignación de bloques en ciertas situaciones, forzando así los datos al disco después de 5 segundos como máximo por defecto.

Me pregunto qué sucede cuando una aplicación sobrescribe partes existentes de un archivo, sin truncar o agregar el archivo en sí. ¿Será forzado a grabar en 5 segundos también?

Parece una situación diferente a la de agregar a un archivo: al agregar, el tamaño del archivo cambia, que es un cambio de metadatos; por lo tanto, será necesaria una confirmación del diario dentro de los 5 segundos, y debido a datos = ordenados, los datos deberán escribirse antes debido a problemas de seguridad (de lo contrario, partes del archivo eliminado de otros usuarios podrían aparecer para el propietario del anexo). archivo).

Al sobrescribir los datos del archivo, no hay ninguna razón por la que la escritura de datos deba realizarse antes de la confirmación del diario de metadatos, ya que los datos antiguos pertenecen al mismo usuario que el nuevo. Entonces, ¿la escritura ocurre antes de la confirmación de todos modos, o puede retrasarse más que el intervalo de confirmación del diario? Si es así, ¿cuánto tiempo?

Actualización: Sé que todo esto es irrelevante al hacer lo correcto, es decir, usar fsync (). (Esta fue la razón principal de toda la discusión sobre ext4 y la pérdida de datos; el problema solo se refería a aplicaciones que no fsync () o no en los momentos correctos). No estoy escribiendo mi propia aplicación, pregunto porque no sé si todas mis aplicaciones hacen lo correcto, y quiero saber un marco de tiempo aproximado para tales escritos "peligrosos". La razón para preguntar es que mi controlador de gráficos causa pánico del kernel regularmente, y quiero saber si tengo que preocuparme por más de los últimos 5 segundos de escrituras de datos.

Puede establecer el intervalo de confirmación en un valor personalizado que, creo, puede ser tan alto como un número entero de segundos sin signo de 32 bits; entonces unos 4 mil millones de segundos, o 136 años. Esto está disponible a través de la commitopción de montaje, que puede poner en práctica de la siguiente manera (esto es solo un ejemplo; también puede configurar esto fstab):

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

El intervalo de confirmación no se basa en ningún tipo de condición, como si los datos se agregan o se sobrescriben los datos existentes o lo que sea. La commitopción de montaje (que por defecto es de 5 segundos si no proporciona la opción de montaje) es equivalente a hacer algo como esto en un shell bash:

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

No confunda data=orderedy este intervalo de sincronización del sistema de archivos global ("intervalo de confirmación" es quizás un término menos significativo para aquellos de nosotros que entendemos la funcionalidad del programa de línea de comandos sync, en cuyo caso puede llamarse mejor el "intervalo de sincronización"). data=orderedtrata sobre el orden en que se actualizan los datos y metadatos (donde data=writebackes "menos seguro / más rápido" y data=journal"más seguro / más lento"). commit=12345678se trata de la frecuencia con la que el propio controlador del sistema de archivos fuerza una sincronización COMPLETA de TODOS los datos sucios / diario / metadatos / lo que sea con los medios físicos. Y sin duda puede configurarlo en 136 años si lo desea, y montar con data=writeback,nobhy programas que no llaman fsync()o sync()tendrán páginas sucias en la RAM durante ...

Actualización: según su contexto en la edición de su pregunta, diría que debe ejecutar su sistema de archivos con opciones de montaje data=journal,commit=1o incluso con la syncopción de montaje, hasta que pueda resolver los pánicos del núcleo del controlador de gráficos. Esto mantendrá la máxima integridad de los datos pero a costa del rendimiento. Especialmente querrá hacer esto si escribe datos en el disco con frecuencia que no puede permitirse perder, y eso es doblemente importante si no "confía" en las aplicaciones que está utilizando para emplear fsync()adecuadamente.

Fuente: aquí y experiencia personal

Cualquiera sea la respuesta a su pregunta, no importa.

El comportamiento expuesto garantizado del sistema de archivos ext4 es que "los datos estarán en el disco después de una llamada sync/ exitosa fsync". Por lo tanto, si tiene una aplicación que le hace hacer esta pregunta, debe insertar llamadas de sincronización en los puntos críticos donde debe garantizarse la integridad de los datos. Si es un usuario preocupado por el mismo problema, puede llamar a la syncutilidad de línea de comandos antes de hacer cualquier comportamiento peligroso que pueda causar un cierre impuro.