Cree rápidamente un archivo grande en un sistema Linux
¿ Cómo puedo crear rápidamente un archivo grande en un sistema Linux ( Red Hat Linux )?
dd hará el trabajo, pero leer desde/dev/zero y escribir en la unidad puede llevar mucho tiempo cuando necesita un archivo de varios cientos de GB de tamaño para realizar pruebas... Si necesita hacerlo repetidamente, el tiempo realmente se acumula.
No me importa el contenido del archivo, sólo quiero que se cree rápidamente. ¿Cómo se puede hacer esto?
Usar un archivo disperso no funcionará para esto. Necesito que al archivo se le asigne espacio en disco.
ddde las otras respuestas es una buena solución, pero es lenta para este propósito. En Linux (y otros sistemas POSIX), tenemos fallocate, que utiliza el espacio deseado sin tener que escribir nada en él, funciona con la mayoría de los sistemas de archivos modernos basados en disco, muy rápido:
Por ejemplo:
fallocate -l 10G gentoo_root.img
Ésta es una pregunta común, especialmente en el entorno actual de entornos virtuales. Desafortunadamente, la respuesta no es tan sencilla como podría suponerse.
dd es la primera opción obvia, pero dd es esencialmente una copia y eso te obliga a escribir cada bloque de datos (por lo tanto, inicializa el contenido del archivo)... Y esa inicialización es lo que consume tanto tiempo de E/S. (¿Quieres que tarde aún más? ¡Usa /dev/random en lugar de /dev/zero ! ¡Entonces usarás CPU y tiempo de E/S!) Sin embargo, al final, dd es una mala elección (aunque esencialmente el valor predeterminado utilizado por las GUI de "creación" de VM). P.ej:
dd if=/dev/zero of=./gentoo_root.img bs=4k iflag=fullblock,count_bytes count=10G
truncar es otra opción, y probablemente sea la más rápida... Pero eso se debe a que crea un "archivo disperso". Esencialmente, un archivo disperso es una sección de disco que tiene muchos datos iguales, y el sistema de archivos subyacente "hace trampa" al no almacenar realmente todos los datos, sino simplemente "pretender" que están todos allí. Por lo tanto, cuando usa truncar para crear una unidad de 20 GB para su VM, el sistema de archivos en realidad no asigna 20 GB, sino que hace trampa y dice que hay 20 GB de ceros allí, aunque sea tan solo una pista en el disco. puede que realmente (realmente) esté en uso. P.ej:
truncate -s 10G gentoo_root.img
fallocate es la opción final (y la mejor ) para usar con la asignación de disco de VM, porque esencialmente "reserva" (o "asigna" todo el espacio que está buscando, pero no se molesta en escribir nada. Por lo tanto, cuando usas fallocate para crear un espacio de disco virtual de 20 GB, realmente obtienes un archivo de 20 GB (no un "archivo disperso", y no te habrás molestado en escribir nada en él, lo que significa que prácticamente cualquier cosa podría estar en allí, ¡algo así como un disco nuevo!) Por ejemplo:
fallocate -l 10G gentoo_root.img
Linux y todos los sistemas de archivos
xfs_mkfile 10240m 10Gigfile
Linux y algunos sistemas de archivos (ext4, xfs, btrfs y ocfs2)
fallocate -l 10G 10Gigfile
OS X, Solaris, SunOS y probablemente otros UNIX
mkfile 10240m 10Gigfile
HP-UX
prealloc 10Gigfile 10737418240
Explicación
Pruebe mkfile <size>myfile como alternativa a dd. Con la -nopción se anota el tamaño, pero los bloques de disco no se asignan hasta que se escriben datos en ellos. Sin la -nopción, el espacio se llena a cero, lo que significa escribir en el disco, lo que implica tomar tiempo.
mkfile se deriva de SunOS y no está disponible en todas partes. La mayoría de los sistemas Linux xfs_mkfilefuncionan exactamente de la misma manera, y no sólo en los sistemas de archivos XFS a pesar del nombre. Está incluido en xfsprogs (para Debian/Ubuntu) o paquetes con nombres similares.
La mayoría de los sistemas Linux también tienen fallocate, que solo funciona en ciertos sistemas de archivos (como btrfs, ext4, ocfs2 y xfs), pero es el más rápido, ya que asigna todo el espacio de archivos (crea archivos que no son huecos) pero no inicializa ninguno. de ello.
truncate -s 10M output.file
creará un archivo de 10 M instantáneamente (M significa 1024 1024 bytes, MB significa 1000 1000 - lo mismo con K, KB, G, GB...)
EDITAR: como muchos han señalado, esto no asignará físicamente el archivo en su dispositivo. Con esto, podría crear un archivo arbitrario de gran tamaño, independientemente del espacio disponible en el dispositivo, ya que crea un archivo "escaso".
Por ejemplo, observe que no se consume espacio en el disco duro con este comando:
### BEFORE
$ df -h | grep lvm
/dev/mapper/lvm--raid0-lvm0
7.2T 6.6T 232G 97% /export/lvm-raid0
$ truncate -s 500M 500MB.file
### AFTER
$ df -h | grep lvm
/dev/mapper/lvm--raid0-lvm0
7.2T 6.6T 232G 97% /export/lvm-raid0
Entonces, al hacer esto, diferirá la asignación física hasta que se acceda al archivo. Si asigna este archivo a la memoria, es posible que no obtenga el rendimiento esperado.
Pero sigue siendo útil conocer este comando. Por ejemplo, cuando se comparan transferencias utilizando archivos, el tamaño especificado del archivo aún se moverá.
$ rsync -aHAxvP --numeric-ids --delete --info=progress2 \
[email protected]:/export/lvm-raid0/500MB.file \
/export/raid1/
receiving incremental file list
500MB.file
524,288,000 100% 41.40MB/s 0:00:12 (xfr#1, to-chk=0/1)
sent 30 bytes received 524,352,082 bytes 38,840,897.19 bytes/sec
total size is 524,288,000 speedup is 1.00
