¿Se descargan los archivos de corta duración en el disco?

Mi programa crea muchos archivos pequeños de corta duración. Por lo general, se eliminan en un segundo después de la creación. Los archivos están en un sistema de archivos ext4 respaldado por un disco duro real. Sé que Linux descarga periódicamente ( pdflush) páginas sucias en el disco. Como mis archivos son de corta duración, lo más probable es que no se almacenen en caché pdflush. Mi pregunta es, ¿mi programa causa muchas escrituras en disco? Mi preocupación es la vida de mi disco duro.

Como los archivos son pequeños, supongamos que la suma de su tamaño es menor que dirty_bytesy dirty_background_bytes.

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

Un experimento simple usando ext4:

Crear una imagen de 100 MB ...

# 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

Conviértalo en un dispositivo de bucle ...

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

Hacer sistema de archivos y montar ...

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

Realice algún tipo de ejecución con archivos 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

Desmontar, sincronizar, desbloquear.

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

Verifique el contenido de la imagen.

# 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, enumeró todos los nombres de archivo, pero ninguno de los contenidos del archivo. Entonces solo los contenidos no fueron escritos.

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

Si realmente desea evitar las escrituras en disco, busque tmpfs ,

Como regla general, no, no se escribirán. Esto se debe a que el caché vacía las páginas sucias cuando se cumple una de dos condiciones:

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

2. Hay muy poca memoria para que el caché contenga los datos, más que dirty_ratiopáginas sucias en el caché (el valor predeterminado es 20%).

Entonces, en un sistema con mucha memoria libre y poco tráfico de escritura aparte de sus pequeños archivos que se eliminan en menos de 5 segundos, los datos no se eliminarán.

El hecho de que los archivos de corta duración se graben en el disco o no depende no solo del comportamiento predeterminado del caché de archivos del núcleo, sino también de los detalles de la implementación del controlador del sistema de archivos y las opciones de montaje de dicho sistema de archivos. Es posible configurar el sistema de tal manera que todo siempre se escriba inmediatamente en el disco (esencialmente, un comportamiento similar al DOS).

Un sistema de archivos, que presenta de manera prominente el comportamiento que le interesa (llamado "asignación retrasada") es XFS. Con él puede estar más o menos seguro (dado que no hay opciones de configuración divertidas en otro lugar) de que los bloques que pertenecen a los archivos recién eliminados se reutilizarán en la memoria, sin acceso intermedio al disco. Es posible que XFS aún desee actualizar su diario de metadatos (que se escribirá en el disco con bastante frecuencia; sin embargo, dado que el diario de XFS es solo metadatos, es lo suficientemente pequeño como para configurarse en otro dispositivo rápido, como la RAM con respaldo de batería encontrada en muchos controladores RAID).

Debido a este comportamiento, no es infrecuente encontrar archivos completamente apagados, sino de otro modo archivos legítimos (tamaño y otros metadatos intactos) en un sistema de archivos XFS después de una interrupción repentina de energía. Tal es un costo de soportar operaciones rápidas de archivos "semi-temporales".

Alguna teoría

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

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

Si el sistema de archivos está montado en modo "sincronización", todos los cambios van al disco inmediatamente (a través de fat_sync_inode () en este caso). De lo contrario, el bloque se marca como "sucio" y permanece en la memoria caché hasta que se vacía en alguna oportunidad razonable.

Por lo tanto, es imposible predecir el comportamiento del sistema con respecto a los archivos transitorios sin considerar las opciones de montaje del sistema de archivos e inspeccionar el código fuente de su implementación (esto, por supuesto, se aplica principalmente a todo tipo de sistemas de archivos exóticos que se encuentran principalmente en el espacio incrustado) .