On 2013-11-11 15:06 +0100, berenger.mo...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131112144029.gc6...@aym.net2.nerim.net
