Re: disks differ after cloning with dd
On 13/11/13 01:40, Andre Majorel wrote:
> 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.
DD_PID=$(ps -eo pid,comm | awk '$2 == “dd” {print $1}')
watch kill -USR1 $DD_PID
>
> 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.
>
Reply to: