DD from /dev/zero to /dev/null...what actually happens

Question

What happens in the command

sudo dd if=/dev/zero of=/dev/null bs=500M count=1. 

Where do the zeros actually go and in general what happens? The speed is 905 MB/s

If I dd to ramdisk the speed is only 388 MB/s. And if I dd to my hdd the speed is only 63.2 MB/s

Answer 1

/dev/zero provides an endless stream of zero bytes when read. This function is provided by the kernel and does not require allocating memory. All writes to /dev/null are dropped silently.

As a result, when you perform the dd, the system generates 500 megabytes in zero bytes that simply get discarded. Except for a temporary buffer, no data are stored before, during, or after this operation.

The speed of the transfer from /dev/zero to /dev/null is determined primarily by the speed of your processor and relevant system calls. (In your case, the buffer is 500 MB large, and hence the operation tests the speed of your memory as well.)

Answer 2

I will translate this command for you:

dd if=/dev/zero of=/dev/null bs=500M count=1

Duplicate data (dd) from input file (if) of /dev/zero (virtual limitless supply of 0's) into output file (of) of /dev/null (virtual sinkhole) using blocks of 500M size (bs = block size) and repeat this (count) just once (1).

In general, this command should measure just memory and bus speeds. However, it may fail if you do not have 500MB of RAM available. So, in a sense, it also implicitly benchmarks how fast your OS can allocate big memory chunks.

Answer 3

/dev/null is a black hole. It is not accurate for testing normal write operations as it doesn't actually write to disk as a normal file would. Rather than have the head write to disk, the data is discarded immediately upon write to the device, so it will always be faster than normal local writes.

/dev/zero is similar for reads. It does not require head movement to read from, it is just a limitless supply of null characters, so it will always read faster than any local read.

In other words, this is like testing in a void and will not give an accurate picture of what normal local reads and writes should yield.

Answer 4

1. /dev/null is nowhere; data written to it are simply deleted.

2. Your ramdisk has a file system it has to use. dd has to create a file system entry and write following the rules of the file system. Also your OS is using your memory for other things at the same time so your write operation gets what is left.

3. Non SSD Hard drives are just plain slow so that is also correct.

Answer 5

As others have noted, this reads from an infinite supply of zeros, and writes to a pseudodevice that discards whatever is written.

A good way to understand what's happening in a case like this in to run it under strace:

% strace -T dd if=/dev/zero of=/dev/null bs=50M count=1

Skipping some startup and shutdown system calls, the heart of what this does is

openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3 <0.000049>
...
openat(AT_FDCWD, "/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 ...
mmap(NULL, 52441088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd61de31000 <0.000046>
read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 52428800) = 52428800 <0.070642>
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 52428800) = 52428800 <0.001773>
close(0)                                = 0 <0.000040>
close(1)                                = 0 <0.000031>

That is:

1. openat to open the two devices for read and write respectively.
2. mmap to allocate a writable 50M buffer.
3. One big read and then one big write.
4. Close the files and exit.

Also interesting in this is that the read (at 70ms on this slow machine, shown at the right of the log) is significantly slower than the write (1ms). The read needs to write zeros over 50MB of process memory. The write, just needs to work out that it's writing to /dev/null and then return success, without actually touching the data.

An interesting thing about this is that strace will actually do the reads and writes, even though from a certain point of view it ought to "know" that /dev/zero will always give zeros and writes to /dev/null are always pointless. (It could be argued that this is useful for benchmarking, but it's a rather unrepresentative benchmark.)

For example if you use sudo strace -T dd if=/dev/zero of=/dev/sdasomething to wipe a disk, you can see it does spend a percentage of its time pointlessly reading pages and pages of zeros from the kernel, instead of allocating zeros once and writing them repeatedly.