[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 100% used / file system. Help!



On 9/21/2011 10:39 AM, Lisi wrote:
On Wednesday 21 September 2011 16:16:31 Stan Hoeppner wrote:
On 9/21/2011 9:14 AM, Lisi wrote:
And I have taken in that /var/log is a likely culprit.

Not necessarily.  On a server /var/log is a likely culprit, but on a GUI
workstation I'd think /var/cache or /usr would be more likely, assuming
the problem is a hosed/misconfigured program.  If the problem is the
result of an errant drag/drop the files causing the undue swelling could
be in any directory you had/have write access to.

# du -s -h /var
# du -s -h /var/log
# du -s -h /var/cache
# du -s -h /var/tmp
# du -s -h /lost+found
# du -s -h /root
# du -s -h /tmp
# du -s -h /usr

/var/cache and /usr are 6 G between them, so are certainly not
small.  /var/log is not very big at all.  But that still doesn't explain the
jump.  Perhaps I have started doing something differently without realising
it.

Tux:/home/lisi# du -s -h /var
2.9G    /var
Tux:/home/lisi# du -s -h /var/log
320M    /var/log

This needs to be addressed. I'd say something's wrong if you have 320MB of log files on a workstation. Find the big one(s) and tell us what they are. One of your daemons is likely being too chatty with a log file, blasting it before each logrotate, or logrotate isn't working properly.

Tux:/home/lisi# du -s -h /var/cache
2.3G    /var/cache

This is probably where your web browser is storing its cached files. Go into browser options and clear the cache. May take a while. Tell us how much space this frees up.

Tux:/home/lisi# du -s -h /var/tmp
43M     /var/tmp
Tux:/home/lisi# du -s -h /lost+found
16K     /lost+found
Tux:/home/lisi# du -s -h /root
3.4M    /root
Tux:/home/lisi# du -s -h /tmp
120K    /tmp
Tux:/home/lisi# du -s -h /usr
3.7G    /usr

That's reasonable for /usr.

None of this adds up to 30GB. You've got a file(s) somewhere else in a subdir of / that's taking up tons of space. Or, you may have a huge sparse file somewhere that got corrupted, causing the filesystem to treat it as its full, non-sparse, size.

Did you tar a huge set of files/dirs recently?

Did you create a disk or partition backup to an image file somewhat recently with some utility? If so, where did you save the image file? Look in that directory for a very large file, tell us the name and size of the file. Run these commands on the file:

# du -h -B1 [file]
# ls -h -l [file]

If the sizes are dramatically different then you have a sparse file. Simply remove this image file. Then unmount the filesystem and run fsck. Due to your partition/filesystem setup, you'll need to schedule the fsck at the next reboot.

I'll do some chatting to Google, and then at least reduce the size of anything
that serves no useful, or anyhow necessary, purpose.

I'd trust the list members here more than Google hits, except maybe hits on Debian Administration. Even in that case many of the Google hits are very old articles that may no longer apply.

--
Stan


Reply to: