i recently created a test file, because I wanted to play around with logrotate. I was searching for a solution to create a file with any size I want. I found out that this is my solution:

dd if=/dev/zero of=/path bs=1M count=30 status=progress 

I also found this:

dd if=/dev/urandom of=/path bs=1M count=30 status=progress

The first example creates a file with zero's, the second one with random text. Both of the files have the same size of 30M.

Can anyone explain, why it takes longer to create this this file with random text than with zero's? Because they both have the same size of data...

Thanks in advance :)

enter image description here

enter image description here


2 Answers 2


As you can see from your output, both methods are quite fast. However, there is a distinct difference between the sources of your data.

  • /dev/zero is a pseudo-file which simply generates a stream of zeroes, which is a rather trivial task
  • /dev/urandom actually accesses the kernel's pool of entropy to generate random numbers and therefore has much more I/O and process call overhead than simply producing the same fixed value all over as would be the case for /dev/zero.

That is the reason why reading from /dev/urandom can never be as fast as reading from /dev/zero. If you are interested, the Wikipedia article on /dev/random can serve as a starting point for further reading.


You're assuming that the file on disk is just a byte-for-byte copy of what comes out of the input device. It doesn't have to be.

There's also another potential difference in performance other than the source of the data (already covered in another answer) - file system compression, deduplication, and potential creation of sparse files.

If you are writing a file of nothing but zeros to a file system that compresses data, all such a file system has to do is keep updating how "big" all those zeros are. That can be done really fast as no information other than the fact that the only content is zero and the number of those zeros ever has to be written to disk.

Truly random data can not be compressed at all.

File systems can also "deduplicate" blocks even when files are not compressed, especially copy-on-write file systems such as ZFS. Only one block of zeros would have to be written to disk on a filesystem that performs deduplication, then only references to that block would have to be added.

Random data is very, very unlikely to produce duplicate blocks.

It's also possible for a file system to detect that the content of a block is all zero and create a sparse file - where nothing has to be written to disk.

All of those can be a lot faster than actually writing all the zeros to disk.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .