Dear documenters, 1. unless there's any technical reason to use a blocksize of 1M, this should be changed. Unfortunately I do not have the insight to judge that, so please check w/ s/o who knows more about this. All images I wrote w/ "bs=1k" so far worked, so I'd assume that either all those images were integer multiples of 1M, or there's no technical reason to pad the end w/ zeroes to the next 1M boundary. Rationale: (AFAIK) The native blocksize of USB media is 4k. Writing an image w/ the native blocksize is about 7 times faster (at least on USB 2). 2. I'd like to suggest to add "status=progress" to the dd(1) arguments, because this command can take a few minutes (on USB 1/2) and it's much nicer to have some reply about what's going on. Somehow like this: "older versions of dd(1) do not support 'status=progress'. If it fails, simply use the command w/o it." I just stumbled over this when I was preparing the media for an installation, and instead of just doing what I used to do ("dd bs=1k conv=sync"), I checked the handbook to see if s/th changed. Nothing changed, but using "bs=1M" was significantly slower than "bs=1k". So I thought: both is wrong, should be 4k! And yes - using "bs=4k" is in fact much faster. The same bad example occurs in the man page of dd(1) (last example) With kind regards, Torsten
My experience and benchmarks differ - from a freebsd stable/11 system to a random USB2 thumb drive, I get a slowdown on the order of 8x from using 4k rather than 64k block size. Block sizes of 64k, 128k, 256k, 1m give me indistinguishable speeds (note, there is basically no reason to ever use a blocksize greater than MAXPHYS when writing to a raw device, and that is 128k in standard builds). All block sizes below 64k are slower for me. status=progress is not needed on freebsd since you can always just use control-T.
After internal discussions the blocksize of 1M should be the better option for most systems, because there's a lot more system calls for example.