Shirt Pocket Discussions

Shirt Pocket Discussions (https://www.shirt-pocket.com/forums/index.php)
-   General (https://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   Troubles (https://www.shirt-pocket.com/forums/showthread.php?t=866)

fyngyrz 11-30-2005 09:38 PM

Troubles
 
Hi. I got a new 300 gb HD for backup of my 80 GB Mac Mini. It is USB2, external (obviously, for a mini.) I have it connected through a dedicated 4-port USB2 hub which in turn is connected to one of the ports on the mini. The other port goes to my KB, then my mouse.

The mini itself is running OSX 10.3.9, latest patches from Apple. I bought it 31 (yes, thirty ONE) days before Tiger was released, so Apple won't upgrade it to Tiger. I, in turn, won't turn it into a $100.00 more expensive machine.

So anyway, I chose SuperDuper as the backup tool, seemed nice. Indicates it'll run under 10.3.9, so that's good. I paid, it's registered. Then I try a backup. Erase, then copy. Not the smart option, just kill the drive, then copy.

SuperDuper begins to back up, then slows down, slower and slower, until it is apparently not doing anything any more. I get about 18 GB saved of 36 GB which actually needs to go. I am using the erase then backup option. This takes many hours. SuperDuper reports about 300,000 files (!?) to back up. I know I've put maybe ten thousand files on there, at least 4,000 jpegs, since I bought the machine (hence my itch to back it up!) TOP reports there are stalled threads; I presume this is the disk-writing portion of SD, yes? No? I kill SD. The drive light is red (means it's writing.) It won't go out. I have to physically unplug it, OSX tells me I'm an idiot and I should have ejected (but of course, I can't, the drive is paying no attention to me, attempts to eject result in declarations that something is using the drive) then I plug it back in, OSX fixes (presumably) the drive as the light goes green, then red, then the drive mounts and goes back to green (I am using the journaled filesystem because I'm a coward.) If I select smart backup at this point, it quickly determines that it has about 18 GB of files on the drive (takes maybe 5 minutes) and then it immediately jams up again with a red light on the drive, same deal. No more files are going on there, apparently.

I have killed everything prior to the backup. Nothing is running but Finder, superduper and whatever system stuff usually happens. Let me put it this way: Nothing but SD and Finder on the task bar have arrows indicating they are running during the backup. I have a gig of ram, which I know is mostly free, unless SD is using it all. I think this other info is irrelevant, but just in case, the mini has bluetooth and wifi and the faxmodem as well as the 80gb drive and 1.42ghz cpu.

Plugging this same HD into a PCs USB2 port, it can be formatted, copy 50 gigs to it no problem (different filesystem so no assurance it's going to the same location on the HD) and the surface scan, running overnight, detects no problems with the drive. Copying 50 gigs to the drive takes about an hour and a half or so.

The Mini, up until this backup exercise, has been uniformly well behaved. Nothing else appears to be wrong.

So. Please do some finger pointing for me. The Mini? SuperDuper? The drive? The hub? Bad files on the Mac? Aliens? George W. Bush?

I know a bit about linux, I realize the mac isn't linux but is somewhat similar here and there, but I don't know where to look or what to look for other than what I've described to you.

I am, as you might imagine, a bit frustrated.

:eek:

--Ben

fyngyrz 11-30-2005 09:43 PM

I forgot...
 
I'm using S-D 2.01 v76.

Sorry. All that text and I didn't give you the version. Duh.

:)

dnanian 11-30-2005 09:50 PM

Did you actually back up directly to the drive, or to an image stored on the drive?

fyngyrz 11-30-2005 09:53 PM

more
 
I used the option the program comes up with, which is, erase, then copy, initially. Then, I modified the options to use smart, so it would only copy new files (I was hoping to get it done incrementally at that point) and it read what was there then jammed up. At that point, the end of log is:

[clipped]
| 11:34:16 AM | Info | /
| 11:34:19 AM | Info | /cores
| 11:34:19 AM | Info | /usr
| 11:34:55 AM | Info | /Users
| 12:59:02 PM | Info | User terminated processing of transcript...

dnanian 11-30-2005 10:06 PM

Yes, but was it directly to the USB drive, or to an image?

If directly to the drive, please plug the drive directly into the USB port, and not into a hub... let's try to simplify this as much as possible.

fyngyrz 12-01-2005 12:15 AM

I used the default, so it went right to the drive, not to an image. I never even saw the option to save to an image, though I understand where it is now. Though I still would have picked this, as it says it's faster than writing to an image. When you look at the 18 GB it writes to the disk by opening the drive in finder, you can see the user folder and various folders inside that folder, and so on. Not a .DMG file or anything like that. Just a standard folder with my stuff in it.

I'll give it another shot tomorrow, and I will take the hub out of the picture. Right now, it's running another long surface test on a PC (and doing fine, so far.) The KB and mouse will work through the hub (in fact, everything I've ever tried will) so if I have to dedicate one of the mini's two ports to the drive, I can do that.

Thanks for the speed of your responses. More tomorrow.

--Ben

dnanian 12-01-2005 09:40 AM

OK, good. I want you to write directly to the drive, and wasn't sure, based on your comments, that you were. (It's quite common that USB drives come formatted as FAT32, and Tiger will even format as FAT32, so you could end up with a drive with a 4GB file limit.)

Anyway -- I don't think the issue is the drive surface, though it's possible. I'd recommend an erase-and-zero (of free and used space) on the Mac, rather than a test on the PC, to actually test, though.

fyngyrz 12-01-2005 08:52 PM

testing on Mac now
 
Ok, I have the drive re-attached to the Mac Mini, directly, no hub. Currently, it is writing the 8x sequence of random values to the drive. Looks like this may take a loooooooooong time, so I hope to post tomorrow that it all went well.

All the PC tests went ok, including a backup of 200 gigs down at our local radio station (on PC, so again, can't presume the surface was used the same.) But that and the two surface tests went fine. If the random write goes ok, I will go back to trying SuperDuper, feeling fairly certain that the drive and the connection to the drive are ok.

dnanian 12-01-2005 11:29 PM

OK -- let me know what happens.

fyngyrz 12-02-2005 02:00 AM

Update... same problem, just faster.
 
Using the por on the mini instead of the hub, copy rates are reported as 9.69 mb/sec instead of 0.85 mb/sec. So the hub... the hub is a bad idea. :) It took only about 35 minutes to get to 18 GB instead of hours and hours.

But the bad news is the backup stops in the same place, at 18.08 GB, with drive locked on write (LED is red.) It's been sitting with the same reading, 18.08 GB, 36,035 of 318,631 files evaluated, 32736 files copied (that's suspiciously close to 2^15th, isn't it? Accidentally use a short integer, perhaps?) 18.08 GB evaluated, 18.08 GB copied.

Still copying right to the drive, still using erase then copy, not smart version.

Your thoughts?

--Ben

dnanian 12-02-2005 08:15 AM

Don't worry, we're not using a short integer. (Seriously -- the standard OSX installation has an awful lot of files, and we'd fail on everything -- one of our standard test systems has way over 1M files.)

I'd check, with "sudo lsof | grep "SDCopy"", to see what file's being read/written (it'll likely be close to the last one listed). My guess is that there's a file there that's being constantly updated, and when we copy it it looks larger than it really is. (See the User's Guide on Troubleshooting for a description of this.)

Let me know if that helps -- and yeah, USB hubs with USB drives are definitely a bad idea. :)

fyngyrz 12-02-2005 01:35 PM

no results
 
Ok. I ran SuperDuper with smart, because I know that it'll hang trying the same file.

I enter the command string to look for open files

The file it is stuck on copying is vk.mpg, which is a large mpeg movie, about 8.08 gigabytes (specifically reported as 8,679,608,945 bytes) and which shows each time I look at it as having 38527 bytes copied, when I re-invoke lsof.

Is the file too large for SuperDuper? I know it's a good mpeg, I've watched it. So that means the file is ok, right? Or no? Is there a way I can test the file itself? It's not being updated, in fact I've not even thought about it for a month or so and have rebooted many times in the interim, so I can't imagine anything (other than SuperDuper) might have a lock on it or otherwise be fumbling around with it.

This file arrived via our network; it was captured on a PC from a videotape we made, then copied through finder to my machine. Any red flags there?

--Ben

bdmcnitt 12-02-2005 03:06 PM

The exact same thing is happening to me -- SD hangs at the same point -- no progress is made and the hard drives spin down.

- Paid version of SD 2.0.1 (v76)
- PowerBook G4
- Tiger
- WiebeTech ToughTech FW800 external drive (2 partitions, both OS X Journaled), FW800 direct connection
- Full erase/backup to dedicated partition

dnanian 12-02-2005 03:20 PM

There's no file size limit that I know of with SD!, Ben, although I don't think I've tested an 8GB file. We use a system call to copy the file (with two alternate paths should a failure be flagged). How long have you left it? It might take some time to copy.

dnanian 12-02-2005 03:21 PM

I believe you and I are dealing with your case in email, bdmcnitt, and I don't think it's at all the same thing. Clearly, Ben can quit, etc, whereas your machine went to sleep and you can't quit...


All times are GMT -4. The time now is 04:47 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.