This question already has an answer here:

In order to test that our systems correctly detect that they are running out of space, we just need large files on the disk where we do not care about their content at all. At the moment we use dd if=/dev/zero [...] to create them which takes awfully long especially when writing multiple hundreds of gigabytes to consumer grade SATA disks.

Is there a way to speed this up? I'm thinking of just writing the information that the file exists to the file system table without writing the content of the file, ending up with a huge file containing whatever was written on the disk before.

marked as duplicate by Takkat, Bruno Pereira, Eric Carvalho, Rmano, karel Mar 5 '15 at 15:18

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


I think that the limitation will be the write BW of your disks. Anyway, it is important too to choose the right blocksize:

⌂89% [romano:~/tmp] % time dd if=/dev/zero of=test1.tmp count=2M
2097152+0 records in
2097152+0 records out
1073741824 bytes (1,1 GB) copied, 12,6078 s, 85,2 MB/s
dd if=/dev/zero of=test1.tmp count=2M  0,37s user 3,18s system 27% cpu 12,721 total
⌂86% [romano:~/tmp] % time dd bs=1M if=/dev/zero of=test1.tmp count=1k
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 11,671 s, 92,0 MB/s
dd bs=1M if=/dev/zero of=test1.tmp count=1k  0,00s user 1,10s system 9% cpu 11,783 total
⌂64% [romano:~/tmp] % time dd bs=100M if=/dev/zero of=test1.tmp count=10
10+0 records in
10+0 records out
1048576000 bytes (1,0 GB) copied, 10,3397 s, 101 MB/s
dd bs=100M if=/dev/zero of=test1.tmp count=10  0,00s user 1,16s system 11% cpu 10,457 total

...as you can see the speed is more or less limited to around 100 MB/s, but the CPU usage varies wildly (the default blocksize of dd is 512 bytes).

The correct solution is fallocate, as in the linked duplicate.


If you use BTRFS, you can easily decrease your file system size:

btrfs filesystem resize <size> <mount point>

Maybe you should set up a test instance in an LXC container or chroot with limited file system space, thus you could test out-of-space and other conditions there.

If you really want to go the way to create a big file, I don't know of a way faster than dd, though theoretically one could assign free blocks to a file without actually writing to those blocks. Though this would need some filesystem-level hacking – maybe fallocate does that, though I never used it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.