Il problema con lo seek=<big number> trucco è che il filesystem è (di solito) intelligente:se una parte di un file non è mai stata scritta (e quindi sono tutti zeri), non si preoccupa di allocare spazio per esso - quindi, come hai visto, tu può avere un file da 10 GB che non occupa spazio (questo è noto come "file sparsi" e può essere molto utile in alcuni casi, ad esempio in determinate implementazioni di database).
Puoi forzare l'allocazione dello spazio con (ad esempio):
dd if=/dev/zero of=filename bs=$((1024*1024)) count=$((10*1024))
che richiederà molto più tempo, ma in realtà riempirà il disco. Raccomando di rendere la dimensione del blocco molto più alta di uno, perché questo determinerà quante chiamate di sistema il dd processo fa:minore è la dimensione del blocco, maggiore è il numero di chiamate di sistema e quindi più lento verrà eseguito. (Anche se oltre 1 MB o giù di lì probabilmente non farà molta differenza e potrebbe anche rallentare le cose...)
Come altra opzione, puoi usare yes insieme a una singola stringa ed è circa 10 volte più veloce dell'esecuzione di dd if=/dev/urandom of=largefile. Come questo
yes abcdefghijklmnopqrstuvwxyz0123456789 > largefile
Hai creato quello che è noto come "file sparsi" - un file che, poiché la maggior parte di esso è vuoto (ovvero si rilegge come \0), non occupa spazio sul disco oltre a quello che è effettivamente scritto (1B, dopo 10 GB di distanza).
Non credo che potresti creare file enormi, occupando spazio su disco effettivo in un istante:occupare spazio fisico significa che il filesystem deve allocare blocchi del disco al tuo file.
Penso che tu sia bloccato con il vecchio "dd if=/dev/zero of=filename bs=100M count=100" che è limitato dalla velocità di scrittura sequenziale dell'unità.