dd está produciendo un archivo aleatorio de 32 MB en lugar de 1 GB

Quería producir un archivo aleatorio de 1 GB, así que utilicé el siguiente comando.

dd if=/dev/urandom of=output bs=1G count=1

Pero cada vez que ejecuto este comando obtengo un archivo de 32 MB:

<11:58:40>$ dd if=/dev/urandom of=output bs=1G count=1
0+1 records in
0+1 records out
33554431 bytes (34 MB, 32 MiB) copied, 0,288321 s, 116 MB/s

¿Qué está mal?

EDITAR:

Gracias a las excelentes respuestas en este tema, llegué con una solución que lee 32 fragmentos de 32 MB de tamaño, lo que hace que 1 GB:

dd if=/dev/urandom of=output bs=32M count=32

Se dio otra solución que lee 1 GB directamente en la memoria y luego escribe en el disco. Esta solución toma mucha memoria, por lo que no se prefiere:

dd if=/dev/urandom of=output bs=1G count=1 iflag=fullblock

bs, el tamaño del búfer, significa el tamaño de una sola llamada read () realizada por dd.

(Por ejemplo, tanto bs=1M count=1y bs=1k count=1kresultará en un archivo de 1 MiB, pero la primera versión lo hará en un solo paso, mientras que la segunda lo hará en 1024 trozos pequeños.)

Los archivos normales se pueden leer en casi cualquier tamaño de búfer (siempre que el búfer se ajuste a la RAM), pero los dispositivos y los archivos "virtuales" a menudo funcionan muy cerca de las llamadas individuales y tienen una restricción arbitraria de la cantidad de datos que producirán por llamada read ().

Para /dev/urandom, este límite se define en urandom_read () en drivers / char / random.c :

#define ENTROPY_SHIFT 3

static ssize_t
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
    nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
    ...
}

Esto significa que cada vez que se llama a la función, fijará el tamaño solicitado a 33554431 bytes.

De manera predeterminada, a diferencia de la mayoría de las otras herramientas, dd no volverá a intentarlo después de recibir menos datos de los solicitados: obtiene el 32 MiB y listo. (Para que vuelva a intentarlo automáticamente, como en la respuesta de Kamil, deberá especificar iflag=fullblock).

Tenga en cuenta también que "el tamaño de una sola lectura ()" significa que todo el búfer debe caber en la memoria a la vez, por lo que los tamaños de bloque masivos también corresponden al uso masivo de memoria por parte de dd .

Y todo es inútil porque generalmente no obtendrá ningún rendimiento cuando supere ~ 16–32 bloques MiB: las llamadas al sistema no son la parte lenta aquí, sino el generador de números aleatorios.

Entonces, por simplicidad, solo use head -c 1G /dev/urandom > output.

ddpuede leer menos de ibs(nota: bsespecifica ambos ibsy obs), a menos que iflag=fullblockse especifique. 0+1 records inindica que se leyeron 0bloques completos y 1bloque parcial. Sin embargo, cualquier bloqueo total o parcial aumenta el contador.

No sé el mecanismo exacto que hace que ddleer un bloque sea menor que 1Gen este caso particular. Supongo que cualquier bloque se lee en la memoria antes de que se escriba, por lo que la gestión de la memoria puede interferir (pero esto es solo una suposición). Editar: esta respuesta concurrente explica el mecanismo que hace que ddleer un bloque sea menor que 1Gen este caso particular.

De todos modos, no recomiendo tan grande bs. Me gustaría utilizar bs=1M count=1024. Lo más importante es: sin iflag=fullblock ningún intento de lectura, puede leer menos de ibs(a menos ibs=1, creo, que esto es bastante ineficiente).

Entonces, si necesita leer una cantidad exacta de datos, úsela iflag=fullblock. Nota iflagno es requerida por POSIX, es ddposible que no la admita. Según esta respuesta, ibs=1 es probablemente la única forma POSIX de leer un número exacto de bytes. Por supuesto, si cambia ibs, deberá volver a calcular el count. En su caso la reducción ibsa 32Mo menos probable que se solucionará el problema, incluso sin iflag=fullblock.

En mi Kubuntu arreglaría tu comando así:

dd if=/dev/urandom of=output bs=1M count=1024 iflag=fullblock