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


9

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.


> Mi programa crea muchos archivos pequeños de corta duración ¿cuánto es 'mucho'? ¿Estás borrando estos archivos o reescribiendo archivos? > También quiero saber si los metadatos o los datos están escritos en el disco. Creo que el modo de metadatos predeterminado está ordenado, lo que significa que los metadatos se confirman antes de que los datos se escriban en el disco. Por supuesto, hay opciones de montaje que puede agregar para cambiar esto. > Mi pregunta es, ¿mi programa causa muchas escrituras en disco? Es difícil responder a esto teniendo en cuenta la información que ha proporcionado. ¿Ha considerado usar herramientas como iotop y sysstat para monitorear el disco IO?
AngryWombat

ReiserFS es mejor para archivos pequeños si realmente quieres que lleguen al disco tmpfs está bien si no te importa
xenoterracide

Algunas aclaraciones: (1). El sistema de archivos ext4 no está montado con la syncopción. Puede considerar un fedora, debian o ubuntu instalado por defecto. Tú eliges uno. (2) Cada archivo tiene aproximadamente 60 KB. (3) Se crean y eliminan alrededor de 1000 archivos por segundo, pero no existen más de 10 archivos en cualquier momento. En otras palabras, el rendimiento de E / S es grande pero el espacio ocupado es pequeño.
Wu Yongzheng

Respuestas:


5

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.


Buen intento. Ahora estoy convencido. También probé ext2 y obtuve el mismo resultado que tú. Cambié su carga de trabajo de E / S paralela a una secuencial y obtuve un archivo de corta duración-999 y un 8 de contenido de corta duración- *. ¿Alguien tiene alguna explicación?
Wu Yongzheng

@msw: editado en caso de que no esté claro. De lo contrario, por favor explique.
frostschutz

Eso es tonto. Los archivos existen al mismo tiempo, no había nada que sobrescribir y los sistemas de archivos no sobrescriben el contenido de los archivos eliminados, ya que dañaría el rendimiento. Pero, por supuesto, use nbdy registre el tráfico (o un método similar para rastrear todas las escrituras).
frostschutz

7

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 ,


2
tmpfs es realmente una buena opción en este caso, pero todavía quiero saber, como una pregunta general del sistema operativo, ¿se escriben los datos en el disco (innecesariamente)?
Wu Yongzheng

Su pregunta debería ser mucho más específica de lo que probablemente pueda formular para recibir una respuesta definitiva. La memoria caché del búfer media una complicada compensación entre rendimiento y persistencia que no se puede responder en abstracto. Usando las herramientas que @AngryWombat enumeró, podría medir las escrituras reales de su aplicación específica, pero hay muchos factores que podrían hacer que varíe de una ejecución a otra.
msw

Bueno, si pdflush viene después de que se elimine el archivo. Escribirlo sería innecesario.
Wu Yongzheng

1

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.


0

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


Gracias por tu respuesta. Parece que ext4 también ha retrasado la asignación. ¿Eso significa que mi respuesta es NO? (dado que no hay opciones de configuración divertidas en otro lugar). ¿Eso también significa que mi respuesta es SÍ si se usa ext2?
Wu Yongzheng

Creo que incluso con ext2 en el kernel moderno, la respuesta será NO. Este tema en particular se discutió mucho y un breve vistazo a la fuente del kernel muestra que el controlador ext2 se basa principalmente en las operaciones "predeterminadas" del kernel para hacer sus cosas (por lo tanto, todo se retrasa por el caché de bloque). Supongo que debería actualizar mi respuesta para incluir información adicional.
oakad

Mi ext4 obviamente no está montado con la syncopción. Nunca haria eso.
Wu Yongzheng

Al marcar un inodo sucio, supongo que el sistema de archivos es responsable de marcar la página correspondiente como sucia. Más tarde, cuando se elimina el inodo, ¿el sistema de archivos limpia la página sucia? Si no, los datos serán vaciados al disco innecesariamente.
Wu Yongzheng

2
Los bloques de datos no utilizados se "liberan", por lo que dejan de estar sucios. Si escribió algunas cosas para archivar, y luego las truncó antes del vaciado, la basura más allá del EOF simplemente desaparece (más o menos). Con los metadatos puede no ser tan simple porque puede haber varias compensaciones con respecto a la integridad de las estructuras de datos del sistema de archivos. Por cierto, no es obvio por su pregunta que siempre espera tener el control total de su plataforma: la mayoría de las aplicaciones generalmente terminan ejecutándose en máquinas de configuración desconocida, lejos del desarrollador.
Oakad
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.