commit 6febdbe1fae3d0912c1133056f55d70819849460
parent ebbc912876e2b317f310fef48dbf52b0c9488681
Author: fjbalon <fbalon@templier.es>
Date: Tue, 16 Jun 2026 16:44:50 +0200
Refactorización de código de dd
Diffstat:
1 file changed, 0 insertions(+), 2 deletions(-)
diff --git a/dd/index.html b/dd/index.html
@@ -95,7 +95,6 @@ echo $base$(echo $unidades | cut -f$i -d, )</code></pre>
16777216 (16M) : 197 MB/s
33554432 (32M) : 189 MB/s
67108864 (64M) : 194 MB/s</code></pre>
-<p>Puede encontrar el script completo en <a href="https://balong.es/git/lab/file/unix/dd/calc-obs.sh.html">git</a>.</p>
<p>Lo que lleva a analizar que un tamaño de bloques definido entre 64K y 512K es suficientemente óptimo, tomando como referencia valores más altos en los que apenas se notaría la optimización (y como detallaré más adelante ofrecerá más riesgo) y valores inferiores, contra los que sí que se observa una clara diferencia, especialmente tomando el valor por defecto.</p>
<p>Para analizar el ibs, debemos indicar el disco como if y copiar el contenido of a <emb>/dev/null</emb>, teniendo una lógica similar a:</p>
<pre><code>BLOCK_SIZE=65536
@@ -128,7 +127,6 @@ done</code></pre>
16777216 (16M) : 193 MB/s
33554432 (32M) : 120 MB/s
67108864 (64M) : 8 MB/s</code></pre>
-<p>Puede encontrar el script completo en <a href="https://balong.es/git/lab/file/unix/dd/calc-ibs.sh.html">git</a>.</p>
<p>Hay que tener en cuenta que, si el tamaño de bloque es, digamos, 1M, dd leerá 1024x1024 bytes y escribirá bytes iguales. Pero si ocurriera un error de lectura, las cosas saldrán mal. Se tiende a pensar que dd llenará los errores de lectura con ceros si usa las opciones <emb>noerror</emb> y <emb>sync</emb>, sin embargo esto no es lo que sucede: dd rellenará el obs con el tamaño del ibs después de completar su lectura, lo que significa que agregará ceros al final del bloque. Es decir, para un disco todo el 1M se estropearía debido a un solo error de lectura de 512 bytes al comienzo de la lectura: <emb>12ERROR89</emb> se convertiría en <emb>128900000</emb> en lugar de <emb>120000089</emb>.</p>
<p>Si tenemos la certeza de que el disco no contiene ningún error, podríamos continuar usando un tamaño de bloque más grande, lo que aumentará la velocidad de su copia varias veces, especialmente siguiendo los parámetros anteriores para una mayor eficiencia. Por ejemplo, en teoría cambiar el bs de 512 a 64K cambiará la velocidad de copia de 35MB/s a 120MB/s, tomando como ejemplo un sistema Celeron de 2.7 GHz. Pero tenga en cuenta que los errores de lectura en el disco de origen terminarán como «errores de bloque» en el disco de destino, es decir, un solo error de lectura de 512 bytes dañará todo el bloque de salida de 64K.</p>
</body>
