Last night, I started downloading a ffew things with FrostWire. No big deal. Everything was going fine until I started another download and suddenly I get a little popup from the system that I'm running low on disk space.

I figured that's okay because I've done that before, so I started to backup the dir's I keep big chunks of stuff in...like my built srcs, and all the installed builds.

Kept getting back the space becausekrusader was showing it, but within 10 seconds I look again and it shows only a few KB's of space left.

Now I'm beginning to fret a little bit.

I open up ksysguard but whatever it is that's eating up the space on my hdd has now got it so ksysguard can't show me anything...it opens up but doesn't 'do' anything, and top was no help.

Now I'm worried and I figure a shutdown and reboot might 'fix' the problem. Nope...system's so busy eating up space that it pops up the little window telling me I'm out of space and won't let me shutdown or logout.

I grit my teeth and do a button shutdown.

Reboot and the filesystem had a buttload to go through doing whatever it does in those situations...I really mean a lot!

The rest of startup is also extremely slow and I'm worried now that I'm out an hdd I cannot afford monetarily.

It finally gets to the login screen (I always set my system for a graphic, because I have a poor memory and severe ADD...it just makes things a lot easier for me, heh). It also is taking its time.

Finally I'm back to my desktop. I open up krusader and voila!...I am back to having 125GB of my 150GB hdd!

I have absolutely no clue what happened, why it happened, how it happened. Never had that happen in 14 years of using linux (3 of those Slackware). I honestly don't think it was FrostWire, because it seemed to be happening *during* the time I started a download and FrostWire came back with an 'error' because the hdd was too full.

Anyway, all seems back to normal, but it was a heck of a trip while it lasted!

Have you checked your hard disk for errors?

Yes, showing all is well.

The system is running better than ever at the moment, nice and fast (the things I backed up on a dvd and then deleted to make space on the hdd only added up to 2GB, so it's not like that should make the system faster than it was *before* the system started the strange filling-up thing).

Just plain weird, lol.

One of the advantages of having multi-filesystem layout is it protects you from run away processes like this.

BTW, reaching for the power button should be an absolute last resort. You might want to read up on "Magic SysRq". alt+SysRq,k would likely have saved you in this case.

How would a multi-filesystem have stopped a runaway process (for example if that's what it was)? Whatever was happening, it was writing to, at the least, my /home hdd (which is on sda and separate from /, /boot and swap which are on sdb). It's possible whatever it was was writing(?) to everything that had an open space on both drives, so that wouldn't have made any difference if I'd assigned 3 different fs's, no? (not meaning that to sound smart-ass, just asking to find out in general and gain a little knowledge)

And yep, I know hitting the power or reset button are a last resort, but since I had no idea what to do since nothing was responding to *anything* I was doing, it was my last resort. And yes, I just looked into the MagicSysRq thing as you suggested and will be setting that up on my system right after I post this, heh. Thanks for that info too on the Magicness.

Usually it's /tmp or / filling up that brings a system to its knees like that. /home filling doesn't normally have such an impact. Nevermind, as there's no evidence as to what was actually happening, it's pretty much all conjecture anyway. I was probably wrong. Forget I mentioned it.

It was definitely the strangest thing that's ever happened to me since I've been using Linux since 2000, heh heh.

The space won't be available until the file is closed by all the processes that has it open.

Rebooting is one way to ensure that has happened.

I got tired of clearing out /tmp, that I symlinked it to a tmpfs mount. Now I don't worry about it anymore.

Yep, /tmp on tmpfs is my choice too. Just out of interest where are you symlinking it to?

Now I'm curious...how is that done, so I can keep that in a file and if things don't look up with this particular install and I have to try again, I just might give it a shot too.

Just add the following line to your /etc/fstab.
Obviously, this will only work for you if you only put small things in /tmp. I use /var/tmp for anything that won't fit.

Do you have a way to automatically spill over to /var/tmp for anything that won't fit in /tmp, GazL? Or is that something you do on a case by case basis, manually or scripted?

Nope, there's nothing automatic I'm afraid. Most well written scripts/programs will respect $TMPDIR so it's usually a case of just setting that before invoking anything big.

Putting /tmp on a tmpfs isn't a silver bullet for tempfile management (especially so if you don't reboot often). The main reason I do it is to avoid unnecessary disks writes, and though it does mean /tmp gets cleared out at every reboot, one has to be mindful that it's still a limited resource that will need to be managed while the system is up.

It works for me though.

This will work for large files also, if you have a large enough swap.