Re: disks differ after cloning with dd
On 2013-11-11 15:06 +0100, berenger.morel@neutralite.org wrote:
> I do not remember having seen so much unused space on first disk.
> Could dd have written stuff there, when I only asked it to read
> there?
dd writing to the argument of if= would be a bug. A major one.
> 2: the 2 disks are USB drives of 500GB. I was very reluctant to
> interrupt the copy, but had no other choice at that point, since it
> was obvious that it entered in some sort of infinite loop... no idea
> why, since dd does not seems to give any details on what it is doing
> ( no verbose mode AFAIK ).
It's not obvious to me that the copy would never have completed.
IME, USB gives you a transfer rate of around 18 MB/s. Copying
500 GB would take 500e9/18e6/3600 = 7.7 hours. Mutiply that by
two if there is contention at the USB level. Furthermore, you
might not even reach that 18 MB/s tranfer rate. A small I/O
block size could slow things down considerably, I suspect.
So more than 24 hours to copy a 500 GB USB disk onto another is
a lot but not inconceivable.
And of course, attempts to read a bad sector can take a very
long time.
I would try to run dd with bs=1M and see if it's faster.
Unfortunately, GNU dd does not have a --progress option but last
time I looked, it responded to signal USR1 by writing its
current stats on stderr. So you can use ps to find out the PID
of your dd(1) process then kill -USR1 <PID> from time to time to
see how far along it is.
If you must stop the copy, dd options seek= and skip= can be
used to restart from where you stopped (as opposed to restarting
from the first block).
conv=noerror could be useful to skip over bad sectors. But make
sure that when dd cannot read a block from the input file, it
does write a block to the output file. Otherwise, the source and
destination would desynchronise and the copy would be unusable.
Karl has mentioned recoverdm. Sounds promising.
--
André Majorel <http://www.teaser.fr/~amajorel/>
Thousands of verified email addresses available from bugs.debian.org.
Reply to: