Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What's the difference between two dd commands that have different bs and count values, as long as they multiply to the same? For example:

  1. dd if=/dev/random of=aa bs=1G count=2
  2. dd if=/dev/random of=aa bs=2G count=1
share|improve this question
Both commands will take ages. Use urandom if you need random numbers. Use zero if you just need fast input of something. – Nils Dec 13 '11 at 20:01
Use /dev/urandom, not /dev/random. See security.stackexchange.com/questions/3936/…, security.stackexchange.com/questions/3259/…, – Gilles Dec 14 '11 at 11:40
Thanks, great tips. – Rocky Dec 15 '11 at 1:40
up vote 25 down vote accepted

As far as the end result is concerned, they will do the same. The difference is in how dd would process data. And actually, both your examples are quite extreme in that regard: the bs parameter tells dd how much data it should buffer into the memory before outputting it.

So, essentially, the first command would try to read 2GB in two chunks of 1GB, and the latter would try to read whole 2GB at one go and then output it to the aa file.

share|improve this answer

The result will be the same but in the first case dd will write two 1GB blocks while in the second one 2GB block. The difference is that dd keeps the copied block in memory. You will need 1GB of RAM in the first case and 2GB in the second.

In my opinion there is no need to use such large blocks. You can do a couple of tests but in my case I achieve a greater speed with much smaller blocks (< 1MB)

share|improve this answer

The first one will take up 1G of memory, fill it with data from the input file and output it, two times.

The second one will take up 2G of memory, fill it with data from the input file and output it.

share|improve this answer

The used block-size should match the best speed settings for source and target device.

You can best see the difference if you try to copy an LV device. The usage of very small BS-size will interrupt the read-process unnecessary. The usage of a very big BS-size will lead to long waits during write.

Since standard LVs consist normally of 4 MB chunks, wich is also a good size for physical disk access I use bs=4M for these.

Try to experiment with 16K or 256M - you will note the difference - and watch the disk indicator during copy...

share|improve this answer
The penalties for small or large block sizes are somewhat offset by the caching performed by the kernel. See here for a mini-benchmark. – Gilles Dec 14 '11 at 11:22
@Gilles I don`t remember the numbers in my tests, but they were far more dramatic than yours. Which physical harddisk-setup did you use in your test? Mine was on a hardware RAID 5 striped across 5 disks (SAS 15k) with 128 KB. stripe size. – Nils Dec 14 '11 at 19:41
SATA disks, no RAID, otherwise idle machine. I don't remember the exact specs. – Gilles Dec 15 '11 at 15:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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