Creación rápida de un gran archivo de bytes aleatorios

Estoy consiguiendo buenas velocidades usando el shred utilidad.

• 2G con dd in=/dev/urandom - 250seg
• 2G con openssl rand - 81seg
• 2G con shred - 39seg

Así que espero unos 3-4 minutos para 10G con shred .

Crea un archivo vacío y tritúralo pasando el tamaño de archivo deseado.

touch file
shred -n 1 -s 10G file

No estoy seguro de la seguridad criptográfica de los datos generados, pero parecen aleatorios. Aquí hay algo de información al respecto.

Hay un programa generador de números aleatorios sharand escribe bytes aleatorios en un archivo. (El programa se llamaba originalmente sharnd, con una letra a menos ( véase http://mattmahoney.net/dc/ )

Se tarda aproximadamente un tercio del tiempo que en leer /dev/urandom

Es un RNG seguro - hay RNG más rápidos, pero no seguros, pero no es lo que se necesita normalmente.
Para ser realmente rápido, busca la colección de algoritmos RNG para perl: libstring-random-perl .

Intentémoslo ( apt-get install sharand ):

$ time sharand a 1000000000                      
sharand a 1000000000  21.72s user 0.34s system 99% cpu 22.087 total

$ time head -c 1000000000 /dev/urandom > urand.out
head -c 1000000000 /dev/urandom > urand.out  0.13s user 61.22s system 99% cpu 1:01.41 total

Y los archivos de resultados - (parecen más aleatorios desde el interior):

$ ls -l
-rw-rw-r-- 1 siegel siegel 1000000000 Aug  5 03:02 sharand.out
-rw-rw-r-- 1 siegel siegel 1000000000 Aug  5 03:11 urand.out

Comparación de los valores de tiempo "total", sharand tardó sólo un tercio del tiempo que necesitó el método urandom para crear algo menos de un GB de bytes aleatorios:

sharand : 22s total
urandom : 61s total

Quieres un archivo especial en Linux, /dev/random sirve como generador de números aleatorios en un sistema Linux. /dev/random eventualmente se bloqueará a menos que tu sistema tenga mucha actividad, /dev/urandom en no-bloqueante. No queremos bloqueos cuando estamos creando nuestros archivos así que usamos /dev/urandom.

prueba con este comando:

dd if=/dev/urandom bs=1024 count=1000000 of=file_1GB conv=notrunc

Esto creará un archivo con bs*count bytes aleatorios, en nuestro caso 1024*1000000 = 1GB. El archivo no contendrá nada legible, pero habrá algunas nuevas líneas en él.

xKon@xK0n-ubuntu-vm:~/tmp$ dd if=/dev/urandom of=file.txt bs=1048576 count=100 conv=notrunc
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 13.4593 s, 7.8 MB/s
xKon@xK0n-ubuntu-vm:~/tmp$ wc -l file.txt
410102 file.txt

Puedes utilizar la opción buscar con dd para acelerar un poco más el proceso:

$ dd if=/dev/zero of=1g.img bs=1 count=0 seek=1G
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 8.12307 s, 132 MB/s
$ ls -lh t
-rw-rw-r-- 1 xK0n  xK0n  1.1G 2014-08-05 11:43 t

Las desventajas aquí son el hecho de que el archivo no contiene nada legible y el hecho de que es bastante más lento que el método /dev/cero (alrededor de 10 segundos para 100Mb).

También te puede gustar el comando fallocate que preasigna espacio a un fichero.

fallocate -l 1G test.img

salida

-rw-r--r--. 1 xK0n xK0n 1.0G Ago 05 11:43 test.img

Dado que no existía una herramienta de este tipo, he creado una herramienta multihilo aleatorio rápido generador de datos.

pip install fastrandom
fastrandom > /dev/yourdisk

El cifrado OpenSSL, como se ha mencionado en otras respuestas, es una de las formas más rápidas de crear datos aleatorios, pero sólo utilizará un núcleo de CPU para hacerlo. Soy capaz de obtener unos 3 GB/s con aes-256-ctr o chacha20, mientras que mi propia herramienta llega a unos 4,5 GB/s en dispositivos reales (11 GB/s a /dev/null).

openssl enc -chacha20 -nosalt -kfile /dev/urandom -in /dev/zero \
| dd of=/dev/yourdisk bs=1M status=progress

Curiosamente, la encriptación parece ser la forma más rápida de producir números aleatorios. Ni siquiera los mejores generadores de números aleatorios modernos, como PCG64, pueden funcionar tan rápido (yo obtengo alrededor de 1 GB/s por núcleo). Ambos métodos producen números pseudoaleatorios perfectamente buenos, así que tiene sentido utilizar simplemente la encriptación para todas las necesidades de PRNG.