seek=<big number> のトラブル トリックは、ファイルシステムが (通常) 巧妙であるということです:ファイルの一部が書き込まれたことがない (したがってすべてゼロである) 場合、そのファイルにスペースを割り当てる必要はありません。スペースを占有しない 10 GB のファイルを持つことができます (これは「スパース ファイル」と呼ばれ、特定のデータベースの実装など、場合によっては非常に役立ちます)。
スペースを強制的に割り当てることができます (例):
dd if=/dev/zero of=filename bs=$((1024*1024)) count=$((10*1024))
これにはさらに時間がかかりますが、実際にはディスクがいっぱいになります。 dd のシステム コールの数が決まるため、ブロック サイズを 1 よりもかなり大きくすることをお勧めします。 プロセスが作る - ブロックサイズが小さいほど、syscall が多くなるため、実行が遅くなります。 (ただし、1MB 程度を超えると、おそらく大きな違いはなく、動作が遅くなる可能性さえあります...)
これに対する別のオプションとして、単一の文字列とともに yes を使用できます。これは、dd if=/dev/urandom of=largefile を実行するよりも約 10 倍高速です。このように
yes abcdefghijklmnopqrstuvwxyz0123456789 > largefile
「スパース ファイル」と呼ばれるものを作成しました。このファイルは、ほとんどが空であるため (つまり、\0 として読み戻されます)、実際に書き込まれるもの (1B、10GB 後) 以外にディスク上のスペースを必要としません。のギャップ)
巨大なファイルを作成して、実際のディスク スペースを瞬時に使用できるとは思えません。物理スペースを使用するということは、ファイル システムがファイルにディスク ブロックを割り当てる必要があることを意味します。
ドライブのシーケンシャル書き込み速度によって制限される、昔ながらの「dd if=/dev/zero of=filename bs=100M count=100」にこだわっていると思います。