Re: dd blocksize
> How about the even more obvious:
> dd if=/dev/zero of=disk-image count=1
If you have the memory, yes.
But what if you want to create a 5 Gigabyte image, e.g. to test a filesystem for large file support or as an image for a DVD-R? dd ... bs=5G needs a system with RAM + SWAP > 5 GBytes, preferably with RAM > 5 GBytes.
It makes no sense to force dd to use the swap, it just slows down everything. The bs argument should be smaller than your available real memory. 1M is a safe bet for old and new systems, and it is fast enough for most cases.
1M is 2048 times the default block size of 512 bytes. To gain the same "boost" again, you would have to use at least 2048 times 1 M, i.e. 2G -- more than many machines can handle without swapping, and already more than many disk caches inside harddisks and optical drives. At this point, increasing block sizes does not gain more performance, but gives a penality because the drives can not use their cache properly. You have to wait for the drive mechanics to find the right track. This takes way much longer than reading from a cache. Cache access time is measured in nanoseconds, disk access time in milliseconds.
dd has options to set the block size to values different from 512 bytes, this reduces the need to fiddle with numbers. For the purpose of creating loop-mountable files, the bs argument is what you want to use. The bs argument accepts common suffixes (k, M, G) for large numbers, at least in GNU's dd.
So instead of
dd if=/dev/zero of=disk-image count=40960
you can use the bs argument with a size of one megabyte, and use a count of 20 to get 20 megabytes:
dd if=/dev/zero of=disk-image count=20 bs=1M
Or, for a floppy image:
dd if=/dev/zero of=dd-floppy count=720 bs=1k
dd if=/dev/zero of=hd-floppy count=1440 bs=1k
dd if=/dev/zero of=ehd-floppy count=2880 bs=1k
bs specifies the number of bytes read into memory with a single read() call and written out with a single write() call. The dd command in the article uses 512 bytes, but issues 40960 read() and 40960 write() calls. My dd command uses a block of one megabyte, but issues just 20 read() and 20 write() calls. This trades memory for syscalls (=speed).
Some peripheral devices prefer large block sizes, e.g. my 48X CDROM spins up to maximum speed only when I use large block sizes (20k up to 1M, preferable equivalent to its internal cache) that result in a fast linear read sequence on the cable. The same applies to image copies between harddisks.
For simple copy purposes from device to device (counting /dev/zero, /dev/null and image files as devices), large block sizes are usually faster because you need way less syscalls.
Especially the pseudo devices /dev/null and /dev/zero have virtually no block size limit and no preferred block sizes. /dev/null just ignores your data and returns a "no error" code, /dev/zero fills the requested buffer with zeros in fast assembler code. So there is no need for small block sizes, except in situations with extreme low memory.