well, this is definately -weird-. If I break down the system only looking at the rootsystem this should be the contents:
/boot (static, kernel)
/bin (static, sysprogs)
/sbin (static, sysprogs)
/etc (static, configs)
/lib (static, libs & modules)
/dev (static, devices, used by trojans to hide dirs in)
/mnt (static, empty)
/misc (static, empty)
/lost+found (fsck dumps)
/proc <- (dynamic, virtual)
/root <- (..)
mounts{
/home
/usr
/var
/tmp}
this means, without deliberate action like installing, core dumps for root, or fsck filling up /lost+found with dumps, the rootsystem -can't- fill this way.
now, clearing out the rootsystem is a serious & destructive task that can only be done locally & manual. Without any knowledge of how the system has behaved in the hours/days before this has happened I cant make any recommendations.
Can u enlighten me a bit on the history of the box? Previous disk problems or other irratic behaviour?
U have tried to find core dumps (rm manually)?
Code:
"find / -name core -print -xdev"
Or files that where -accessed- x minutes or n*24 hrs before u noticed the fillage?
Code:
"find / -amin x -print -xdev"
Code:
"find / -atime +n -print -xdev"
Then theres searches on size, but depending on if it is one large file or lotsa small files ud have to shift size y, k is for kilobytes.
Code:
"find / -size yk -print -xdev"
for each -print will print the filename and -xdev doesnt descend into other filesystems. maybe a good idea to umount all mounts cuz I dont know how to keep it from following mounts.
*btw, I found a free package at sourceforge.net called ext2resize but it shouldnt be used on a live system or with valuable data.