¿Hay alguna manera de determinar el valor óptimo para el parámetro bs a dd?

En ocasiones, he visto comentarios en línea como "asegúrate de establecer 'bs =' porque el valor predeterminado tardará demasiado" y mis propias experiencias extremadamente poco científicas de "bueno, eso pareció tomar más tiempo que ese otro tiempo la semana pasada "parece confirmar eso. Entonces, cada vez que uso 'dd' (generalmente en el rango de 1-2 GB) me aseguro de especificar el parámetro de bytes. Aproximadamente la mitad del tiempo utilizo el valor especificado en la guía en línea desde la que copio; el resto del tiempo elegiré algún número que tenga sentido de la lista 'fdisk -l' para lo que supongo que es el medio más lento (por ejemplo, la tarjeta SD en la que estoy escribiendo).

Para una situación dada (tipo de medio, tamaño de bus o cualquier otra cosa importante), ¿hay alguna forma de determinar el "mejor" valor? ¿Es fácil de determinar? Si no, ¿hay una manera fácil de llegar al 90-95% del camino? ¿O es "simplemente elige algo más grande que 512", incluso la respuesta correcta?

He pensado probar el experimento yo mismo, pero (además de ser mucho trabajo) no estoy seguro de qué factores afectan la respuesta, por lo que no sé cómo diseñar un buen experimento.

dddata de cuando era necesario traducir las viejas cintas de mainframe de IBM, y el tamaño del bloque tenía que coincidir con el utilizado para escribir la cinta o los bloques de datos se omitirían o truncarían. (Las cintas de 9 pistas eran delicadas. Me alegro de que hayan muerto hace mucho tiempo). En estos días, el tamaño del bloque debería ser un múltiplo del tamaño del sector del dispositivo (generalmente 4KB, pero en discos muy recientes puede ser mucho más grande y muy pequeño) las unidades pueden ser más pequeñas, pero 4KB es un punto medio razonable independientemente y cuanto más grande, mejor para el rendimiento. A menudo uso bloques de 1 MB con discos duros. (Tenemos mucho más memoria para tirar estos días también).

Solo hay una forma de determinar el tamaño de bloque óptimo, y esa es una referencia. Acabo de hacer un punto de referencia rápido. La máquina de prueba es una PC con Debian GNU / Linux, con kernel 2.6.32 y coreutils 8.5. Ambos sistemas de archivos involucrados son ext3 en volúmenes LVM en una partición de disco duro. El archivo fuente es de 2GB (2040000kB para ser precisos). El almacenamiento en caché y el almacenamiento en búfer están habilitados. Antes de cada carrera, vacié el caché con sync; echo 1 >|/proc/sys/vm/drop_caches. Los tiempos de ejecución no incluyen una final syncpara vaciar los búferes; la última synctoma del orden de 1 segundo. Las sameejecuciones fueron copias en el mismo sistema de archivos; las diffejecuciones fueron copias a un sistema de archivos en un disco duro diferente. Por coherencia, los tiempos informados son los tiempos de reloj de pared obtenidos con eltimeutilidad, en segundos. Solo ejecuté cada comando una vez, así que no sé cuánta variación hay en el tiempo.

             same   diff
dd bs=64M    71.1   51.3
dd bs=1M     73.9   41.8
dd bs=4k     79.6   48.5
dd bs=512    85.3   48.9
cat          76.2   41.7
cp           77.8   45.3

Conclusión: un gran tamaño de bloque (varios megabytes) ayuda, pero no dramáticamente (mucho menos de lo que esperaba para copias de la misma unidad). Y caty cpno te va tan mal. Con estos números, no creo que ddvalga la pena molestarse. Ir con cat!

Estoy de acuerdo con geekosaur en que el tamaño debe ser un múltiplo del tamaño del bloque, que a menudo es 4K.

Si desea encontrar el tamaño del bloque stat -c "%o" filenamees probablemente la opción más fácil.

Pero digamos que sí dd bs=4K, eso significa que sí read(4096); write(4096); read(4096); write(4096)...

Cada llamada al sistema implica un cambio de contexto, lo que implica una sobrecarga y, dependiendo del planificador de E / S, las lecturas con escrituras intercaladas podrían hacer que el disco realice muchas búsquedas. (Probablemente no sea un problema importante con el planificador de Linux, pero no obstante, algo en lo que pensar).

Entonces, si lo hace bs=8K, permite que el disco lea dos bloques a la vez, que probablemente estén muy juntos en el disco, antes de buscar otro lugar para hacer la escritura (o para dar servicio a E / S para otro proceso).

Por esa lógica, bs=16Kes aún mejor, etc.

Entonces, lo que me gustaría saber es si hay un límite superior donde el rendimiento comienza a empeorar, o si solo está limitado por la memoria.

Como dice Gilles, puede determinar el parámetro óptimo para la opción bs a dd mediante la evaluación comparativa. Sin embargo, esto plantea la pregunta: ¿cómo puede comparar convenientemente este parámetro?

Mi respuesta tentativa a esta pregunta es: use dd-opt , la utilidad en la que recientemente comencé a trabajar para resolver precisamente este problema :)

Optimicé para sdcard reader usb2.0 que parece funcionar mejor bs=10M. Intenté 4k, hasta 16M, después de 8-10M no hubo mejora. Puede ver cómo se degrada la medición de la velocidad de transferencia ... muy probablemente debido a que carga las memorias intermedias en el dispositivo y luego espera a que el dispositivo se transfiera al medio real.

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s