Hace un tiempo, hubo una discusión sobre la posibilidad de que ext4 deje archivos vacíos después de un desmontaje sucio, lo cual se resume bastante bien.en este articulo. Básicamente, debido al retraso en la asignación, las escrituras se pueden mantener en la caché de escritura durante un tiempo mucho más largo 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í que los datos se guarden en el disco después de un máximo de 5 segundos de forma predeterminada.
Me pregunto qué sucede cuando una aplicación sobrescribe partes existentes de un archivo, sin truncarlo ni agregarlo. ¿Se verá obligado a grabar en el disco en 5 segundos también?
Parece una situación diferente a la de agregar un archivo: al agregar, el tamaño del archivo cambia, lo cual es un cambio de metadatos; por lo tanto, será necesaria una confirmación del diario dentro de los 5 segundos y, debido a que data=ordered, los datos deberán escribirse antes por motivos de seguridad (de lo contrario, partes de los archivos eliminados de otros usuarios podrían aparecer para el propietario del archivo adjunto). archivo).
Cuando simplemente se sobrescriben datos de archivos, 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í, ¿por cuánto tiempo?
Actualización: Sé que todo esto es irrelevante cuando se hace lo correcto, es decir, usar fsync(). (Ésta 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 que no estaban en los momentos correctos). No estoy escribiendo mi propia aplicación, lo pregunto porque No sé si todas mis aplicaciones hacen lo correcto y quiero saber un plazo aproximado para escrituras tan "peligrosas". El motivo de la pregunta es que mi controlador de gráficos provoca ataques de pánico en el kernel con regularidad y quiero saber si tengo que preocuparme por más de los últimos 5 segundos de escritura de datos.
Respuesta1
Puede establecer el intervalo de confirmación en un valor personalizado que, creo, puede ser tan alto como un número entero sin signo de 32 bits en segundos; es decir, unos 4 mil millones de segundos, o 136 años. Esto está disponible a través de la commitopción de montaje, que puede implementar de la siguiente manera (esto es simplemente un ejemplo; también puede configurarlo en 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 5 segundos si no proporciona ninguna 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 global del sistema de archivos ("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 sería mejor llamarlo "intervalo de sincronización"). data=orderedse trata delordenen el que se actualizan los datos y metadatos (donde data=writebackes "menos seguro/más rápido" y data=journales "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/diarios/metadatos/lo que sea sucios con los medios físicos. Y ciertamente puede configurarlo en 136 años si lo desea, y montarlo con data=writeback,nobhprogramas que no llaman fsync()o sync()que tendrán páginas sucias en la RAM durante... varias vidas.
Actualización: según el 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 problemas del kernel del controlador de gráficos. Esto mantendrá la máxima integridad de los datos, pero a costa del rendimiento. Especialmente querrás hacer esto si escribes con frecuencia datos en el disco que no puedes permitirte perder, y eso es doblemente importante si no "confías" en las aplicaciones que estás utilizando para emplearlas fsync()adecuadamente.
Fuente: aquíy experiencia personal
Respuesta2
Cualquiera que sea la respuesta a tu pregunta, no importa.
Elgarantizado expuestoEl comportamiento del sistema de archivos ext4 es que "los datos estarán en el disco después de una llamada sync/ exitosa fsync". Entonces, si tiene una aplicación que le hace hacer esta pregunta, debe insertar llamadas de sincronización en los puntos críticos donde se debe garantizar la integridad de los datos. Si usted es un usuario preocupado por el mismo problema, puede llamar a la syncutilidad de línea de comandos antes de realizar cualquier comportamiento peligroso que pueda causar un cierre incorrecto.