Why does dd copy slower with really small and really big block sizes?

Question

I have realized that if I use really small block sizes, the dd copy is slower, but if I use really big block sizes, it also is slow. I have found that 1M is optimum.

Why is this?

Answer 1

The answer to your question depends on the type of device you're using, as well as the settings of your file system (if you are writing to a file, instead of the device/partition itself).

Flash Memory

Flash memory (USB drives and SSDs) has hardware sectors that can't be modified without changing the whole sector, so changing one bit results in reading the whole sector, changing this bit and rewriting the sector again.If you have to do this for every bit in your sector, this might take much longer than writing one sector at once (In reality, this probably works a bit different, because the device has it's own buffer to collect data before actually writing to sectors).

Harddrives

When using a harddrive, the block size that works best depends on the actual buffersizes used in hardware and software. But as to what I think, the block size used with gparted isn't as important on harddrives as on flash devices.

I'm not an expert in how storage devices and filesystem drivers, as well as the drivers in the different unix kernels work, so please correct me if I'm telling something wrong.

Answer 2

Probably to do with block sizes on the disk you're copying from/writing to. Block sizes/buffer sizes/read ahead settings all have an impact especially on a sequential read/write. If you use small block sizes, the drive will only read x amount of data per access before passing it on to the next process. Making x bigger x->X allows more data to be lifted in a single read. The "sweet spot" you're seeing is probably optimum for your hardware and operating system.