22

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

Sathyajith Bhat
  • 61,800
agz
  • 8,278
  • 21
  • 73
  • 112
  • 4
    /dev/null is a good destination for testing/timing read operations. /dev/zero is a good source for testing/timing write operations. Combining this source and destination in one operation doesn't make much sense. Not even sure if this provides any meaningful overhead number. – sawdust Apr 09 '13 at 00:18
  • @sawdust Other way around, no? – Jamie Feb 26 '14 at 18:37
  • 2
    Yes, @sawdust, your comment above is nasty (for newbies). of=/dev/sda will overwrite someone's hard drive partitions, contents, etc. of=~/bigfile.tmp would have been a better example to use... – Kevin Traas Jun 02 '15 at 16:32
  • 3
    I know I'm pretty late to the party, but in case anyone wants to try this for themselves: there's no need to run this command as root, and hence no need for sudo. – Roel Schroeven Jul 25 '16 at 08:48
  • @Jamie Nah, it's the right way. – Awn Oct 15 '17 at 13:06
  • I think 905MB/s is your memory bandwidth. Of course, it's different with network bandwidth and disk bandwidth. https://en.wikipedia.org/wiki/Memory_bandwidth – Brutal_JL Dec 03 '18 at 09:32

5 Answers5

22

/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.)

bwDraco
  • 46,155
14

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.

mvp
  • 4,390
  • 1
    If it measures memory, how come writing to a ramdisk is significantly slower? – agz Apr 09 '13 at 19:48
  • 5
    Because ramdisk still have to be formatted to have a filesystem, which must be maintained by kernel driver. That also means writing to ramdisk will have overhead of copying data from userspace into kernel space - not exactly free. With /dev/zero or /dev/null, this overhead is almost zero. – mvp Apr 09 '13 at 21:09
  • 1
    I'd never seen "duplicate data" before. I recall reading in old SunOS man pages that dd stands for "copy & convert" (cc was taken). – Dan Pritts Jan 19 '18 at 21:27
7

/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.

MaQleod
  • 13,215
2

  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.

amc
  • 105
cybernard
  • 14,007
0

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.

poolie
  • 193