SD hangs / freezes while doing "backup - all files"

[macnatic]

Hi Folks,
This particular problem has been lingering for 2 days now. I have browsed and read the posts here on the forum but could not get the solution to solve the issue.
I have a new Western Digital 250GB ATA hdd housed in an external USB 2.0 case, which has an HFS+ parition w/ journaling scheme created by Disk Utility. My box is a G5 2.7GHz, running Mac OS v.10.4.1.
I set SD to do "Backup - all files". Since this is not a registered version, i cant elect "Smart Update" but that's another issue entirely. In any case, I let Disk Utility to check, verify, and repair the source volume prior to the backup. I also ensured that all my personal startup items were disabled during login. The destination volume and source volume was named "iStorage" and "Macintosh HD" respectively. Since the external drive(DV) runs USB protocol, i did not have to care about having the destination volume's name the same as the source volume since i cant boot from USB drive anyway.
In the middle of backup, SD would hang and the activity LED on the external case would cease lighting up, an indication that the destination volume/hdd was idle. Checking on the Activity Monitor's Disk Activity & Disk Usage modules confirmed this particular state. The "freeze" incidents have occured 4 times and each backup attempt(after doing a reboot of course) lasted for hours with the progress bars stayed on a particular % value indefinitely. The system would hang(pointer > beachballing), "Force Quit Applications" module would not start, keyboard combinations/command to bring the system down would not function and a hard reboot is the only way.
I checked the SD's log and did not see any particularly alarming activity, but i might be mistaken since i am a new mac user. I have enclosed SD's log file as well as my System Profiler report.
Thanks in advance for any suggestions or helps.

Best Regards,
yoha

[dnanian]

macnatic -- the forums here are probably not the best place to handle support with attachments and stuff, as they're available to everyone who browses -- not necessarily what you'd want.

That said, it sounds like your drive is failing, which is why the I/O subsystem is hanging during the copy. I can't see any errors in your system.log, though, so it's hard to know for sure: you might want to open Console and view the system log during the backup operation to see if it starts spitting out failures.

Anyway, what I'd try first is to:

- Use Disk Utility to erase *AND ZERO* the external drive
- Simplify the bus completely -- detaching everything but the USB drive and reboot
- Open console and view the system.log
- Try the backup again

Let me know what happens!

[macnatic]

Hi Dave,
Dont worry, i have excluded "private" information from the attachments prior to posting. I am going to do you suggested, although i dont think the drive was failing(it might, i am gonna run a thorough diagnostic check on it) since it has been running under windows box for a few weeks w/ no problem.
I will update you on this issue. Thank you

Best Regards,
yoha

[dnanian]

Understood. Realize, though, that SuperDuper! runs at a very high level, just copying files using standard OS calls. If the system is hanging, it's likely because something is interfering with I/O... that's why I'm pointing in that direction...

[macnatic]

Hi Dave,
I got myself a brand new retail hdd this afternoon and currently i am trying to do the backup again. I still dont know whether the problem stemmed from the hdd itself, the external enclosure's chipset, or my mac. It is interesting to note that moving the external drive that was plugged in one of the USB ports @ the back of the mac box to the front USB port, delay the crash event quite a bit. Although all usb n firewire ports @ the back of the box are used, i am not sure if my mac is overloaded with external peripherals causing this I/O problem.

In any case, SD is currently backing up to the new hdd. So far so good, but it has only been 5 minutes. I also noticed the following output from the system.log: "ComputerName kernel[0]: jnl: flushing fs disk buffer returned 0x5" every few seconds. Is this a normal behavior? i googled, yahooed, and msned it, but nothing comes up from the string.

1 more thing, your mentioned on your last response "...SD runs at high level, just copying files using standard OS calls...". I thought i cannot simply cp folders from the source to the destination just like that due to the structure and so on. I might misunderstand you.

Best Regards,
-y0ha

[dnanian]

Um, no. That's not normal at all, y0ha. There's something funny going on here: basically, when it tries to flush the journal cache, it looks like it's failing (or giving some kind of weird error).

On the last response: we're using standard low-level calls, not cp. In other words, we don't ever access hardware directly: we're using the OS to do it, so if there are hardware changes/problems, we're isolated from them.