On 03/02/2017 11:57 PM, Robert Moskowitz wrote:
The following worked:
# dd if=/dev/sdb of=cubietruck.img bs=512 count=6268927
6268927+0 records in 6268927+0 records out 3209690624 bytes (3.2 GB, 3.0 GiB) copied, 114.435 s, 28.0 MB/s
So bs= IS the drive blocksize.
This is the result of trying a number of different values for bs and count.
You can set bs to a multiple of 512 and it will go a lot faster. If I have to use raw dd for cloning, I will factor the count all the way down to primes, and multiply the blocksize by all of the factors up to the largest prime factor. This is trivially easy on a CentOS system (factor is part of coreutils):
[lowen@FREE-IP-92 ~]$ factor 6268927 6268927: 7 43 59 353
So you could use 512 times any of these factors, or several of these factors. I would probably use the line: dd if=/dev/sdb of=cubietruck.img bs=9092608 count=353 Note that while dd can use the abbreviation 'k' you would not want to use that here since 2 is not one of the factors of your count. A roughly 9MB blocksize is going to be loads faster than 512, but still manageable.
Or you could make it easy on yourself and use either dd_rescue or ddrescue. When I was working on the ODROID C2 stuff last year I built ddrescue from source RPM early on, before it got built as part of the EPEL aarch64 stuff. Either of these two will figure out the optimum blocksize for you for best performance, and you get progress indications without having to have another terminal open to issue the fun 'kill -USR1 $pid-of-dd' command to get that out of dd. The ddrescue utility for one includes a '--size=<bytes>' parameter so that you can clone only the portion you want.