My root partition (/dev/sda1) is full. Okay, I know this is frequently asked, but the time has finally come. I've been trying to solve this problem for a few months. I'm running Slackware 12.1 with jfs on / and /home, but this still happened on 12.0 when I was running reiserfs on both.

This is not necessarily cause for concern (everything still runs fine), except that

* Sometimes when I untar something, I get "no space left on device"
* I had a 6gb root partition, then when I installed Slackware 12.1 (fresh install), I made /dev/sda1 10gb, thinking that would prevent it from filling up
* I can't find the offending files; I've searched every Linux and Unix forum and mailing list on the web, and the usual suspects (/var/log, /tmp, /var/tmp) are not the culprits; each user has $TMP set to his or her own ~/tmp, as well as KDEVARTMP=~/tmp
* I was running sshd, thinking that /var/log/messages was filling up with ssh attacks; now that I've shut it off, deleting /var/log/messages does not solve the problem
* I run rsync backups nightly -- could it be stowing temporary files someplace?

So the real problems are:
* What causes it? i.e. how do I stop this from happening?
* How do I find the offending files, and delete them?

I've tried all the du, df, find and all that, and I don't find any single file that's over a gigabyte. Any other ideas?

Here's the output of df:

Like I said, this is mainly irritating because of the occasional errors when "manually" installing (or updating) software, and that I don't know why it's happening.

Another note, I had a similar installation at work, running similar backups, and this never happened. That was behind a VPN.

Thanks for any suggestions,
Joel

*MY* usual way of doing this is to do "du -h --max-depth=1 /" and then see the main offenders in terms of top level directory, then replace / with /tmp, /var etc... as that command gave you, and then just keep localising it. i'd certainly assume it'd be something in /var unless you've just generally been install happy, with vast amounts of data in /usr

Hi,

You could trim your installation to allow more space on '/dev/sda1'. Or you could attach another drive with more space to your '/'. A good candidate would be to move your '/usr' to that available space then mount via your '/etc/fstab'. Just make sure that you have growth on the new '/usr/'. Looking at your '/dev/sdb1 39G 5.0M 39G 1% /mnt/hd' indicates good place to start.

Run this as root. It will list all the files and folders > than 1GB in size.

The regex is very simple, but should work since your / partition is less then 10GB.

For individual files I suggest using the find command. The man page has an example near the end.

You didn't do anything weird and set your block sizes huge did you?

Edit:
Make that
The -x makes sure that it only checks that filesystem.

Thanks everybody, these are some really helpful replies.

@shadnowsnipes: here's the output of the command you suggested:
@acid-kewpie:/media is an external disk mount point.

I guess that means I have been "install-happy." I did install Gnome and a few other things. I will delete some stuff and see how long it takes for this to happen again. I certainly don't need vim :P

I like having sshd running, but it's useless sine I'm moving in three days.

Hmmm...my operations have been low on the weirdness side. All I've done is install software (I didn't think I could have installed 5GB, but it looks like I did). Can you clarify? What would I have done to set the block size of what to do what?

I was saving the /,/usr,/var,/tmp,/home setup for my next install, but maybe I should have done it this time.

Thanks so much --- this forum is great,
Joel

well there's still a fair few gig i can't see accounted for there. what about / itself? any nasty stuff there, maybe core files?

btw, add an -x to my du command... so it would only count that single partiton.

what is this?
It's weird because your / partition according to df has 9.3GB, but du only shows 5.7GB. 3.6GB is a lot to be unaccounted for.

I'm guessing that your space got filled up because of GNOME. 9.3GB is plenty of room for a full slack install and quite a few packages. GNOME probably took up the rest. What GNOME did you install and how did you do it?

For completeness, you might want to add a --apparent-size to the du command to see if it differs (is bigger).

One thing that might be worth checking is whether anything is hiding underneath your mount points in /mnt or /media.
If your backup script failed to mount the /mnt/backup for example but didn't catch the error and continued on regardless it would write data into the /mnt/backup directory in the root filesystem. Then when a later run sucessfully mounts that filesystem it hides the fact this has happened. I'd suggest unnmounting /mnt/hd /mnt/backup and /media/multimedia etc.. if possible and run the du's again to check whether this is what has happened.

edit: underneath /home might also be worth a look if you find nothing anywhere else.

Did you already reboot your system? If not, there might be a process hanging around, that keeps a deleted file open. lsof | fgrep 'deleted' should give you a hint, if there's an open, but deleted file, that invisibly occupies 3G of your hd.

Gnome Virtual File System.

gnomeslackbuild.org/

Joel

This appears to be what happened. I umounted my backup partition, then went to /mnt/backup, and there was a backup of my entire /home partition.

Bingo!

Thanks so much!

I'll post the backup script at http://www.unc.edu/~adamsonj/software.html once I fix it.

Slackware is the best. This happened with PCLinuxOS and I just reinstalled...
Joel