Rut Roh, something just eate up 150 gigs of my Primary disk and I have no idea where (1 Viewer)

[Sam Posten]

It might have been Transmission, I just installed it to download the Chrome Beta. I knew I didnt want to put a frigging Bittorrent client on my mac but I wanted the beta and by all accounts Transmission gets firm thumbs up.

But SOMETHING is eatting up my hard disk space and my system is about to crash.

Nothing in ps -eaf looks hinky

I did a quick look through the directory structure and didnt see anything out of the ordinary.

Any ideas?

Sam

 

[Christian Behrens]

Grand Perspective should be able to help you out.

-Christian

 

[Sam Posten]

Will try that, I had a drive use program installed but it wasn't snow leopard compatible

 

[mattCR]

If you haven't secured transmission, it's web interface (http://localhost:9091/) is easy to expose, and many people hijack it to "add" torrents to it and turn your box into a seeder for them, especially those who want to participate in sites that require upload rates.

I'd check your transmission load.

 

[Sam Posten]

I deleted Transmission and my hard disk seems to have stabilized. Can you tell me where to see if I have a leftover cache of stuff it used? Do I need to do something to relock my system?

 

[Sam Posten]

Quote:

Originally Posted by Christian Behrens

Grand Perspective should be able to help you out.

-Christian

It doesnt show anything super obvious as being bigger than it should be at least as one big file.

http://farm3.static.flickr.com/2671/4142356757_e3e48544e6_o.png

Swirling through all the little files didntt show any major areas of concern either...

 

[Sam Posten]

Think I found it. Same old problem, I've had this before. For some reason Carbon Copy Cloner doesnt find my external disk and it goes ahead and makes a new volume label. So Tube1 becomes Tube1 1 and its near impossible for me to see it cause /Volumes is hidden by default. I actually saw something that said that Transmission used to have a bug where it would create hidden "ghost" partitions in /Volumes so I went poking around in there via Terminal, and that's where I saw it. I am pretty sure it wasn't Transmission that did it cause its happened to me in the past, but just to be safe I got rid of Transmission, Handbrake, Parallels and a bunch of other crap apps I don't use...

 

[Sam Posten]

OK, I REALLY narrowed it down and have this figured out now!

I run my mac pro 24/7, often having it in sleep mode for hours at a time with no problem. Usually when Apple comes out with a system update they require you to reboot your machine, which kills the fun 'uptime' stat =) When that happens I usually just hit no and tell it I will reboot later after applying the patch and shut it down for real overnight and boot it up normally the next day.

My 3 CCC events are set to do my backups in the middle of the night.

CCC will NOT wake your mac up that I have found, so normally if my machine is sleeping during the scheduled backup as soon as I wake it up it goes to work.

BUT, if its a fresh boot and my external drive is not online it doesn't find the /Volumes listing for my external drive so IT MAKES ONE OF ITS OWN! Thats right, CCC makes a duplicately named device so when my external comes online it gets made the name /Volumes/Drive 1

Thats right, there's a frigging SPACE in the volume nane! BUT it shows on the desktop as simply the Drive name, no space, no 1!

So I SEE the device and all looks groovy, yet behind the scenes CCC is eating a section of my /Volumes area with a doppelganger that LOOKS JUST LIKE my external drive, yet is sucking all the space out of my Primary partition.

WORSE, there doesnt appear to be a way for me to stop this from happening. If I miss a backup session while my machine is shut down, I HAVE to eject the external for safety sake, go into terminal and sudu kill -9 all the CCC threads that are running, and theres usually like a dozen of em, then go sudu rm -R the fake /Volumes area, replug in the hard disk and manually tell CCC to run the backup for those that it missed. Theres no way anyone without even a journeyman's knowledge of Unix is going to be able to do that!

So, until I get this straightened out, I gotta remember never leave the machine turned off during a scheduled backup session, tho sleep is fine!

I did learn something else interesting, apparently Parallels is running some stuff at startup too. I uninstalled Parallels from my apps directory and those are still there. Gotta figure out how to get rid of those too!

 

[Sam Posten]

I'm now in contact with Mike Bombich and he and I are working on my issues and seeing how I might handle this better in my own set up. I got an extraordinarily detailed response from him and am really impressed with his suggestions so far.

More to follow, but I will say this: Indy OSX devs rule!

 

[Sam Posten]

This guy is AMAZING. If you haven't gotten CCC, go do it tonight!

Hi Sam: I must have read and re-read your log files at least 6 times over the last two weeks. The issue finally popped out at me, and I was able to build a reproducible test case. I have also robustly resolved the problem, and discovered the underlying issue in Mac OS X that is causing the grief. Typically when a volume disappears in the middle of a backup task, CCC will get the "volume disappeared" notification from the OS and it will abort the backup task immediately. I actually didn't have that abort implemented for scheduled tasks, though, only for the manual method. As a result, CCC didn't stop your three scheduled backup tasks when the volume was unmounted. Take a look at the CCC.0.log file that you sent me, that's where the mayhem started. Ignore the first task listed, it was fine. What happened next was that you shut down the system, and you didn't turn it back on until the scheduled task execution times had expired. Once the tasks were reloaded on startup, CCC immediately fired off the tasks. The following occurred within the same second: 1) The tasks were loaded2) The tasks indicated that no user had yet logged in (you either don't have autologin enabled, or it just hadn't gotten that far yet -- that's fine, CCC works within these parameters)3) Because no user had logged in, external volumes (including the target) were not available. Each task attempted to mount the volume.4) The mount initially appeared to fail, and the tasks rescheduled themselves, leaving open the option of running immediately when the target disk reappeared5) The target disk was successfully mounted6) The tasks all recognized that the target disk "re" appeared and initiated their jobs7) Mac OS X forcefully unmounted the target disk8) The jobs continued to back up to the previous mountpoint, which was now a folder on the boot volume The scheduled tasks should have aborted at step 7 -- that's my bug. However, when Mac OS X attempts to unmount a volume, it sends out a "volume unmount approval" notification to anyone that cares (e.g. CCC). If apps respond with "OK, sure" or not at all, the unmount proceeds. If any app responds with an error status or busy status, the OS is supposed to not unmount the volume. This typically works, but for whatever reason, this is not the case upon initial startup -- the OS is asking for permission to unmount the target, CCC is dissenting, and the OS is unmounting it anyway. Fortunately, that last issue is easy to workaround, I'll simply delay backup tasks for a few seconds in that scenario. Take-aways:• Your configuration is fine, CCC can be expected to operate normally in this configuration• The attached version resolves both issues, so you shouldn't see the boot-volume filling up as a result of a CCC scheduled task.

Let me know if you encounter any issues with this version. Thanks,Mike

Sam

 

[DaveF]

Sam, that's great. It's really something getting that immediate and personal attention from the smaller developers.

I'll add in that I've received fast and personal support from the SuperDuper! developer, Dave N. (You can choose either CCC or SD and know you'll get a good app and good support).