For a long time, I always thought that the bs and count parameters for dd were merely for human convenience; as dd would just multiply them and use the byte value. A month ago, when installing Ubuntu for my mother, I shrunk a partition to the right (don’t ever do that, it takes ages) and saw gparted calculating an ‘optimal block size’.
My question: does the same idea about an optimal ‘block size’ apply for dd apply? If so, are there any specific situations in which it applies most strongly? How can I use the block size to my advantage?
Does the same idea about an optimal ‘block size’ apply for dd apply?
I think so. Consider a buffer of 4kb. It can be filled by a simple mmap operation if the filesystem also has 4k blocks (common on newer flash disks). If one stream fills the buffer, and then the buffer has to be written, the input stream is blocked until the buffer is flushed. This is the reason for using more than one buffer. On the other hand I assume that a single buffer must first be filled, before it is written to the output. So even if there is already some data available, the buffer must be hold in memory. If you use a 1Gig buffer (or block size), this wouldn’t be optiomal, too.
I just had a look at the buffer size in gparted, and it seems they just switch between 128kb and 256kb (might be more complex), and it looks like they want to make most of the caches found in most systems. Given a disk cache of 2MB, it might make sense to transfer data in blocks of that size, and those blocks might even fit in the CPU cache if no mmapped io is used.
If so, are there any specific situations in which it applies most strongly?
All operations that transfer much data, if the data can be read and written blockwise.
How can I use the block size to my advantage?
Calculating it by testing which one is the fasted for you. Its that simple and given the explanations above you might have a good start with something around 256k as a blocksize. Or add an autobufsize option to dd :).