Escribir en una subcarpeta es más rápido que escribir en su carpeta principal

Escribir en una subcarpeta es más rápido que escribir en su carpeta principal

Utilizo dd para medir el rendimiento de escritura y observé algo extraño: escribir en /data/emzed2 es más rápido que escribir en /data. Esta es la forma en que medí el rendimiento:

$ dd si =/dev/cerode=/datos/emzed2/archivo de pruebabs=32

^C4921834+0 registros en

4921834+0 registros 157498688 bytes (157 MB) copiados, 2,87329 s,54,8 MB/s

$ dd si =/dev/cerode=/datos/archivo de pruebabs=32

^C2487991+0 registros en

2487991+0 registros copiados 79615712 bytes (80 MB), 2,6501 s,30,0 MB/s

Ambas carpetas están en la misma partición en una unidad SSD. Utilizo Ubuntu 14.04 y repetí el experimento varias veces con resultados similares.

Tienes idea de lo que está pasando ?

Respuesta1

Parece que te afectan las optimizaciones ext4.. Algunos de ellos se describen enDiseño de disco Ext4documentación.

Cada vez que crece un archivo, por ejemplo con dd, se asigna algún lugar para los nuevos datos. Con el tiempo, el archivo podría fragmentarse, es decir, los datos podrían distribuirse en varios fragmentos a través del disco. La fragmentación es una fuente bien conocida de lentitud (al leer y escribir) y, por lo tanto, las implementaciones de sistemas de archivos a menudo intentan evitarla. La fragmentación es mucho más costosa con discos giratorios (la cabeza necesita viajar a fragmentos sucesivos) que con SSD, sin embargo, la mayoría de las implementaciones de sistemas de archivos utilizan estrategias optimizadas para discos giratorios con SSD.

Una combinación de los "trucos" tercero, cuarto y quinto descritos en la documentación mencionada anteriormente.podríaexplique por qué escribir en el subdirectorio es más rápido en su caso.

El quinto truco consiste en dividir el volumen del disco en grupos de bloques de 128 MB. […] Cuando se crea un directorio en el directorio raíz, el asignador de inodos escanea los grupos de bloques y coloca ese directorio en el grupo de bloques menos cargado que puede encontrar.

Como resultado, emzed2probablemente se creó en un bloque vacío de 128 MB.

El cuarto truco es que todos los inodos en un directorio se colocan en el mismo grupo de bloques que el directorio, cuando sea posible.

En consecuencia, /data/testfilese crea en un grupo de bloques raíz (probablemente muy cargado), mientras que /data/emzed2/testfilese crea en un grupo de bloques (probablemente vacío) emzed2.

El tercer truco […] es que intenta mantener los bloques de datos de un archivo en el mismo grupo de bloques que su inodo.

Para /data/emzed2/testfile, el sistema de archivos primero asignará todos los bloques de datos en el emzed2grupo de bloques. Si este bloque estaba inicialmente vacío, para los primeros 128 MB, esto significa que no hay fragmentación alguna. Para /data/testfile, el sistema de archivos primero llenará el grupo de bloques raíz si aún no lo está y luego buscará otros lugares para almacenar datos.

Además, está haciendo crecer el archivo 32 bytes a la vez. Afortunadamente, los sistemas de archivos como ext4 asignan más datos de los que usted solicita (en trozos de 8 kb en el caso de ext4) e intentan retrasar la asignación. Probablemente verías un patrón similar con bs=8196, pero la diferencia de velocidad podría disminuir con bloques de mayor tamaño.

información relacionada