¿Los files de corta vida se tiñen en el disco?

Mi progtwig crea muchos pequeños files efímeros. Por lo general, se eliminan dentro de un segundo después de la creación. Los files están en un sistema de files ext4 respaldado por un disco duro real. Sé que Linux periódicamente pdflush ( pdflush ) páginas sucias en el disco. Dado que mis files son de corta duración, lo más probable es que no estén en caching por pdflush . Mi pregunta es, ¿mi progtwig causa muchas grabaciones en el disco? Mi preocupación es la vida de mi disco duro.

Como los files son pequeños, supongamos que la sum de su tamaño es menor que dirty_bytes y dirty_background_bytes .

Ext4 tiene el diario pnetworkingeterminado activado, es decir, diario de metadatos. También quiero saber si los metadatos o los datos están escritos en el disco.

Solutions Collecting From Web of "¿Los files de corta vida se tiñen en el disco?"

Un experimento simple usando ext4:

Crea una image de 100MB …

 # dd if=/dev/zero of=image bs=1M count=100 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.0533049 s, 2.0 GB/s 

Haz que sea un dispositivo de bucle …

 # losetup -f --show image /dev/loop0 

Hacer sistema de files y montar …

 # mkfs.ext4 /dev/loop0 # mount /dev/loop0 /mnt/tmp 

Haga algún tipo de ejecución con files de corta duración. (Cambie esto a cualquier método que prefiera).

 for ((x=0; x<1000; x++)) do (echo short-lived-content-$x > /mnt/tmp/short-lived-file-$x sleep 1 rm /mnt/tmp/short-lived-file-$x ) & done 

Umount, sync, unloop.

 # umount /mnt/tmp # sync # losetup -d /dev/loop0 

Verifique el contenido de la image.

 # strings image | grep short-lived-file | tail -n 3 short-lived-file-266 short-lived-file-895 short-lived-file-909 # strings image | grep short-lived-content | tail -n 3 

En mi caso, enumeraba todos los nombres de los files, pero ninguno de los contenidos del file. Entonces, solo los contenidos no fueron escritos.

A less que esté hablando de una unidad de estado sólido, una gran cantidad de grabaciones de disco no será el factor dominante en la longevidad de la unidad.

Si realmente desea evitar las escrituras de disco, investigue en tmpfs ,

Como regla general, no, no se escribirán. Esto se debe a que la memory caching vacía las páginas sucias cuando se cumplen una de estas dos condiciones:

  1. Los datos se /proc/sys/vm/dirty_writeback_centisecs después de /proc/sys/vm/dirty_writeback_centisecs , que por defecto es de 5 segundos.

  2. Hay muy poca memory para que la memory caching retenga los datos, más que las páginas sucias de dirty_ratio en la memory caching (el valor pnetworkingeterminado es 20%).

Por lo tanto, en un sistema con mucha memory libre y poco tráfico de escritura aparte de los files pequeños que se eliminan en less de 5 segundos, los datos no se eliminarán.

Que los files de corta duración se escriban en el disco o no depende no solo del comportamiento pnetworkingeterminado del caching de files del núcleo, sino también de los detalles de la implementación del controller del sistema de files y de las opciones de assembly de dicho sistema de files. Es posible configurar el sistema de tal forma que todo siempre se escriba inmediatamente en el disco (esencialmente, comportamiento similar al de DOS).

Un sistema de files, que destaca el comportamiento que le interesa (denominado "asignación retrasada") es XFS. Con él puede estar más o less seguro (dado que no hay opciones de configuration divertidas en otro lugar) de que los bloques que pertenecen a los files recién eliminados serán reutilizados en la memory, sin acceso a disco intermedio. XFS aún puede querer actualizar su diario de metadatos (que se escribirá en el disco con bastante frecuencia; sin embargo, dado que el diario de XFS solo es metadata, es lo suficientemente pequeño para configurarse en otro dispositivo rápido, como la memory RAM con respaldo de batería). en muchos controlleres RAID).

Debido a este comportamiento, no es raro encontrar completamente a cero, pero por lo demás, los files de apariencia legítima (tamaño y otros metadatos intactos) en un sistema de files XFS después de una interrupción de energía repentina. Tal es el costo de soportar operaciones rápidas de files "semi-temporales".

Alguna teoría

En general, una llamada al sistema que accede a un sistema de files finaliza, bastante rápido, en el método definido por el controller del sistema de files (adjunto a "struct inode_operations" y "struct file_operations" cuando se registra el controller VFS). Lo que sucede después de eso se deja únicamente a discreción de la implementación del sistema de files. Normalmente, se utiliza algo parecido al siguiente enfoque (este ejemplo simple es del controller FAT de Linux):

 if (IS_DIRSYNC(dir)) (void)fat_sync_inode(dir); else mark_inode_dirty(dir); 

Si el sistema de files está montado en modo "synchronization", todos los cambios se transfieren inmediatamente al disco (a través de fat_sync_inode () en este caso). De lo contrario, el bloque se marca como "sucio" y permanece en la caching de la memory hasta que se enjuaga en alguna oportunidad razonable.

Por lo tanto, es imposible pnetworkingecir el comportamiento del sistema con respecto a files transitorios sin considerar las opciones de assembly del sistema de files e inspeccionar el código fuente de su implementación (esto, por supuesto, se aplica principalmente a todo tipo de filesystems exóticos encontrados en el espacio integrado) .