PDA

View Full Version : Disk corruption on cloned copies


jofallon
02-28-2007, 11:19 AM
After my iPod nano locked up yesterday, it messed up my USB ports; I rebooted my G5 by powering off when it hung on a shutdown / restart. I ran disk utility on the external firewire drives when I restarted, when I noticed messages about the journal being replayed on the restart.

Disk utility found and recovered a few hundred corrupted files /inodes when it ran on an external cloned volume. It found the corrupted inodes on the other firewire clone, and strangely enough on the second internal hard drive I use for the third SD clone backup. After fixing all the errors, I rebooted from an external drive, and ran first disk utility and then Disk Warrior 4 on the main internal drive. Neither found any errors on the internal drive.

Given that three cloned copies made on successive days had the same or similar errors, I'm wondering if SuperDuper is somehow the cause, since it seems to be the common factor. All three drives were mounted at the time of the crash, but none of them was being written to. There were no errors found on the iPod, or on the source drive. If the errors had been only on the two partitions on the external firewire drive, I'd think it was a hardware problem with that drive. But I had the same errors with the second SATA drive; and none with the source drive.

I usually have Firefox open when I do a clone, but nothing else in the way of application programs. But I have TechTool Pro installed (more or less the current version), and there are probably other background things that might somehow interfere with the clone operation.

Where might I look to diagnose the problem? Is it possible something interfered with the SD operation, or messed up some file SD needs to run correctly, but without SD giving any error message?

I've usually got a Palm TX and the 2nd generation iPod nano attached to a USB hub, but I wouldn't think they'd mess up writes to a firewire or SATA drive.

Thanks for any help!

dnanian
02-28-2007, 11:24 AM
SuperDuper! runs at a very high level, and never interacts with the lower-level aspects of the file system (such as inodes) -- we just copy files. If the system doesn't give us errors when we copy the files (and, if you have inode problems, those issues might not affect the higher-level stuff), we don't know anything's wrong.

It's quite possible that when you force-shut-down, though, it corrupted the various drives that were connected...

jofallon
02-28-2007, 11:35 AM
That's pretty much what I thought; although why the connected drives would get corrupted and not the main drive I can't understand. I upgraded to SD 2.14 last night and did an erase and full clone this morning. When I get home I'll see if it had any problems. Could something have corrupted the SuperDuper code on disk without it giving any error?

It doesn't seem likely to me.

dnanian
02-28-2007, 11:39 AM
It's hard to know what state all the drives were in when you crashed... nor what had happened to them before.

I can't see how SD! could have been corrupted in a way that would produce no errors but would corrupt low-level disk structures. We just don't have any code that would be messing around down there.

jofallon
02-28-2007, 12:33 PM
That's what I thought. If SD got corrupt, it wouldn't run.

I suspect those partitions were corrupt before the crash, but I can't think how I could check that. I've never had corruption like that before.