El problema con el seek=<big number> El truco es que el sistema de archivos es (generalmente) inteligente:si una parte de un archivo nunca se ha escrito (y, por lo tanto, solo tiene ceros), no se molesta en asignarle ningún espacio, por lo que, como ha visto, usted puede tener un archivo de 10 GB que no ocupa espacio (esto se conoce como "archivo disperso" y puede ser muy útil en algunos casos, por ejemplo, ciertas implementaciones de bases de datos).
Puede forzar la asignación del espacio con (por ejemplo):
dd if=/dev/zero of=filename bs=$((1024*1024)) count=$((10*1024))
lo que llevará mucho más tiempo, pero en realidad llenará el disco. Recomiendo hacer que el tamaño del bloque sea mucho mayor que uno, porque esto determinará cuántas llamadas del sistema dd hace el proceso:cuanto más pequeño sea el tamaño del bloque, más llamadas al sistema y, por lo tanto, más lento se ejecutará. (Aunque más allá de 1 MB probablemente no hará mucha diferencia e incluso puede ralentizar las cosas...)
Como otra opción para esto, puede usar yes junto con una sola cadena y es unas 10 veces más rápido que ejecutar dd if=/dev/urandom of=largefile. Me gusta
yes abcdefghijklmnopqrstuvwxyz0123456789 > largefile
Ha creado lo que se conoce como un "archivo disperso":un archivo que, debido a que la mayor parte está vacío (es decir, se lee como \0), no ocupa espacio en el disco además de lo que realmente está escrito (1B, después de 10 GB de espacio).
No creo que pueda crear archivos enormes, ocupando espacio real en el disco en un instante:tomar espacio físico significa que el sistema de archivos necesita asignar bloques de disco a su archivo.
Creo que está atascado con el anticuado "dd if=/dev/zero of=filename bs=100M count=100", que está limitado por la velocidad de escritura secuencial de su unidad.