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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
