[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: disks differ after cloning with dd






On Mon, Nov 11, 2013 at 7:06 AM, <berenger.morel@neutralite.org> wrote:
Hello.

Few days ago, I tried to clone a damaged[1] disk to another one, of the same size, with dd.
I had to interrupt the copy after more than 24 hours, because it was obviously too long[2].

Now, I am trying to look anew how to do the copy, and looking at the disks with gparted, I have those messages when it inspects the target of the copy:
======
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
Could not detect file system.
======
What is strange, is that it seems to detect all file systems: fat32 for a small first partition (which is bootable... I could take a look at it, it sounds promising. It is labeled "EFI", I wonder what it is...), hfs+ for the bigger one (~465GB), and some non allocated space. Lot of it: 128GB.
Looking at the source disk, I have the same results, but without the error message and with "unknown" as 2nd file system.

I made the error of not writing somewhere informations of the damaged disk before trying to clone it.

The questions I have:
How could an interrupted dd "fix" a file system?
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?
How could I fix that endless copy, or at least how could I know why or what dd is copying endlessly?


1: at least one of it's partitions is: the problem being that, after plugging it into a windows system, content suddenly disappeared. It was previously (only?) used on a mac system. Those disks are not mine so I do not have a lot of knowledge about how they were used.
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 ).


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] dcc0114e11146a5eb561413bc5d092b5@neutralite.org" target="_blank">http://lists.debian.org/dcc0114e11146a5eb561413bc5d092b5@neutralite.org


Berenger,

For 500GB disks with bad sectors the time you said is not unheard of.  Sorry.
I would let it run till it finishes or until errors out.  If it errors out because of bad sectors, I have used dd_resuce with some success.  
As to why it fixed something, hard drives when they hit a bad sector will try to relocate the data on it as best as it can to a good sector and then mark the defective sector as unusable.   When you where doing the dd read on the disk it probably ran into this and relocated the data.  This would be my best guess.
As for the unused 128GB that had to be there to begin with.  dd will only read from the source and write to the destination.   

I hope this helps.

--
Shane D. Johnson
IT Administrator
Rasmussen Equipment



Reply to: