skip to Main Content

I get this output on very single commandline listed below:

0+1 records in
0+1 records out
33554431 bytes (34 MB, 32 MiB) copied, 0.14532 s, 231 MB/s

Here are the different options I tried:

a) dd if=/dev/random of=/dev/null status=progress bs=1G count=1

b) dd if=/dev/urandom of=/dev/null status=progress bs=1G count=1

c) dd if=/dev/urandom of=/dev/null status=progress bs=100M count=1

d) dd if=/dev/urandom of=/dev/null status=progress bs=50M count=1

e) dd if=/dev/random of=/dev/null status=progress bs=50M count=1

f) dd if=/dev/random of=/dev/null status=progress bs=33M count=1

g) dd if=/dev/urandom of=/dev/null status=progress bs=33M count=1

This dd if=/dev/urandom of=/dev/null status=progress bs=10M count=1 is doing as expected and outputs:

1+0 records in
1+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0518184 s, 202 MB/s

I tried this with MX Linux (Kernel 5.10) and with KDE neon and with Ubuntu 20.04

Does someone have a under-the-hod answer? Or some possible ideas?

2

Answers


  1. From the Linux man pages:

    Since Linux 3.16, a read(2) from /dev/urandom will return at most
    32 MB

    The reason has to do with the fact that it’s a special character file interfacing with an underlying driver rather than a "regular" file. The underlying driver clamps the output size to 32 MB in this case. Another answer here provides more details on this matter.

    Login or Signup to reply.
  2. bs, the buffer size, means the size of a single read() call done by dd.

    (For example, both bs=1M count=1 and bs=1k count=1k will result in a 1 MiB file, but the first version will do it in a single step, while the second will do it in 1024 small chunks.)

    I came with solution that reads 32 chunks 32 MB large which makes 1GB:

    dd if=/dev/urandom of=output bs=32M count=32
    
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search