Das Problem mit dem seek=<big number> Der Trick besteht darin, dass das Dateisystem (normalerweise) schlau ist:Wenn ein Teil einer Datei noch nie beschrieben wurde (und daher nur aus Nullen besteht), macht es sich nicht die Mühe, dafür Platz zuzuweisen - also, wie Sie gesehen haben, Sie kann eine 10-GB-Datei haben, die keinen Speicherplatz beansprucht (dies wird als "Sparse-Datei" bezeichnet und kann in einigen Fällen sehr nützlich sein, z. B. bei bestimmten Datenbankimplementierungen).
Sie können die Zuweisung des Speicherplatzes erzwingen mit (zum Beispiel):
dd if=/dev/zero of=filename bs=$((1024*1024)) count=$((10*1024))
was viel länger dauern wird, aber tatsächlich die Festplatte füllen wird. Ich empfehle, die Blockgröße viel größer als eins zu machen, da dies bestimmt, wie viele Systemaufrufe dd sind Prozess macht - je kleiner die Blockgröße, desto mehr Syscalls und desto langsamer läuft er. (Obwohl es bei mehr als 1 MB oder so wahrscheinlich keinen großen Unterschied macht und die Dinge sogar verlangsamen kann ...)
Als weitere Option dazu können Sie das yes zusammen mit einer einzelnen Zeichenfolge verwenden und es ist etwa 10-mal schneller als das Ausführen von dd if=/dev/urandom of=largefile. So
yes abcdefghijklmnopqrstuvwxyz0123456789 > largefile
Sie haben eine sogenannte "Sparse-Datei" erstellt - eine Datei, die, weil das meiste davon leer ist (d.h. als \0 zurückgelesen wird), keinen Platz auf der Festplatte einnimmt, abgesehen von dem, was tatsächlich geschrieben wird (1B, nach 10GB der Lücke).
Ich glaube nicht, dass Sie riesige Dateien erstellen können, die sofort tatsächlichen Speicherplatz beanspruchen - wenn Sie physischen Speicherplatz beanspruchen, muss das Dateisystem Ihrer Datei Festplattenblöcke zuweisen.
Ich denke, Sie stecken mit dem altmodischen "dd if=/dev/zero of=filename bs=100M count=100" fest, das durch die sequentielle Schreibgeschwindigkeit Ihres Laufwerks begrenzt ist.