PDA

View Full Version : running time


cvos
12-07-2005, 07:00 PM
While running SD it starts to copy fine, then hangs. i tried both backup "all files" and "user files" and both seem to hang. it stops at approx. 100 MB copied, and then just sits. how long is backup supposed to take - this ran for 30 min. Both backups (disk images on same drive as regular system) mounted, and i could see folders and files in them

im on a 400mz G4 10.4.3

| 02:49:59 PM | Info | Copy script command COPY supersedes command IGNORE for /Users
| 02:49:59 PM | Info | /
| 02:50:01 PM | Info | /bin
| 02:50:01 PM | Info | Ignoring /bin
| 02:50:01 PM | Info | /usr
| 02:50:01 PM | Info | Ignoring /usr
| 02:50:13 PM | Info | /.Spotlight-V100
| 02:50:13 PM | Info | Ignoring /.Spotlight-V100
| 02:50:13 PM | Info | /.Trashes
| 02:50:13 PM | Info | Ignoring /.Trashes
| 02:50:13 PM | Info | /.vol
| 02:50:13 PM | Info | Ignoring /.vol
| 02:50:13 PM | Info | /Applications
| 02:50:13 PM | Info | Ignoring /Applications
| 02:51:22 PM | Info | /automount
| 02:51:22 PM | Info | Ignoring /automount
| 02:51:22 PM | Info | /Network
| 02:51:22 PM | Info | Ignoring /Network
| 02:51:22 PM | Info | /cores
| 02:51:22 PM | Info | Ignoring /cores
| 02:51:22 PM | Info | /Users
| 03:20:45 PM | Info | User terminated processing of transcript...

many thanks

dnanian
12-07-2005, 07:14 PM
Are you running with a FileVault volume, cvos? If so, at that point it would be copying the (very large) sparse image which -- as mentioned in the User's Guide -- you should log out from...

Could that explain the delay?

cvos
12-07-2005, 08:54 PM
no, filevault is not enabled. under what circumstances should one quit SD, and upon quitting, is it possible to resume to get a full backup?

sincerely

dnanian
12-07-2005, 08:57 PM
In general, you shouldn't have to quit SD in the middle. But if you do, Smart Update won't re-copy the stuff that's already copied -- thus, it'll resume.

I don't have much information about what's going on here, but what I'd suggest is running it again.

When it feels like it's stuck, please run:

sudo lsof | grep SDCopy

in Terminal (copy/paste, then press return if necessary and enter your password, followed by return -- your password won't echo).

The last line or two will show you the file currently being copied. It might give a hint about what's going on...

xochi
12-12-2005, 09:35 PM
I am having similar issues. I've discovered two things:

1. When SD is copying a single, really large file, the progress bar won't update until the file is done. Usually, the CPU usage is only 5% or so when this is happening. This is nothing to worry about.


2. On my system, SD seems to be get hung on on folders with really high #s of files (i.e. 5000+). In this case, performance drops from about 3000 files/sec to about 10 files / sec, and CPU usage spikes to 85% or more. I think this is a bug in SD (see other thread).

So, you may want to check your CPU. If it's pegged near 100%, then SD is probably working but may be stuck in the "slow performance large folder" problem. It will eventually finish, but may take a loooooooong time.

If CPU is near 5% then SD may just be copying one really large file, and should move along quickly and update the user interface when it's done.

dnanian
12-13-2005, 09:14 AM
One thing to check here, xochi, is whether that folder is exceptionally fragmented. Since we're going to be accessing every one of the files' information, it's quite possible that a fragmented, large folder will cause OSX itself trouble.

xochi
12-13-2005, 02:14 PM
One thing to check here, xochi, is whether that folder is exceptionally fragmented. Since we're going to be accessing every one of the files' information, it's quite possible that a fragmented, large folder will cause OSX itself trouble.

Good question. As it happens, I was using SuperDuper prior to installing a larger hard drive in my powerbook, which was nearly full. So fragmentation could be an issue.

I'm now duplicating the tests on my 120 gig drive (40 gig free) which would have no fragmentation at all (since it was just copied over from scratch).

Test 1
1. In apple Mail, I renamed a mail folder that has about 5000 messages.
2. Ran super-duper using smart update option.
Results: although it slowed down when got to the 5000 files, it still was able to process several hundred files per second (not the 10 or so that I was seeing before). SuperDuper was able to scan 80 gigs (updating about 225mb) in about 9 minutes. No problems here.


Test 2
1. In apple Mail, I renamed the mail folder that holds ALL my list mail (about 70,000 files).
2. Ran super-duper using smart update option.

Results: slower, but still was able to do things pretty fast (about 24 minutes).


So, maybe my original problem was related more to file system fragmentation than anything else?

dnanian
12-13-2005, 03:38 PM
That sounds more like it. When you renamed the folder, we'd have to add 70,000 files and remove 70,000 others, but it sounds like the filesystem was the underlying issue there, not SD! itself.

Thanks for following up!