Where did my space go?

Hornpipe2

Hornpipe2

Code: 
greg-kennedy# pwd
/var
greg-kennedy# df -h .
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1d    1.2G    1.1G     32M    97%    /var
greg-kennedy# du -sm .
120     .

So... where is my other 900mb? My database crashed because it ran out of room on /var. But I don't know where in the heck my space went!
 
Code: 
greg-kennedy# du -h /var | grep M
2.4M    /var/db/pkg
 89M    /var/db/portsnap/files
 90M    /var/db/portsnap
1.1M    /var/db/mysql/lbf
 23M    /var/db/mysql
116M    /var/db
2.3M    /var/mail
119M    /var

Only 119M accounted for. Why does du show 1 gig missing?
 
[cmd=]cd /var && du -h -d 1[/cmd]; find the biggest one, cd into it, and run [cmd=]du -h -d 1[/cmd] again.

If you can't find what's eating your space, drop to single-user mode ([cmd=]shutdown now[/cmd]), unmount /var ([cmd=]umount /var[/cmd]) and see what's in the /var directory/mountpoint.
 
You guys! My /var mount point has 1.2gb capacity, of which 1.1gb is reported used by df. du -h /var is _supposed_ to show (human-readable) used capacity of everything beneath it. I am telling you that du -h /var is only showing 119MB used while df -h /var is showing 1.1GB used. Running du -h recursively etc. is not going to help me figure out what the big file is, because du obviously doesn't know where my space went.

My question: what the heck is causing this discrepancy?! I'll try the single-user mode suggestion when I have some free time to work at it. Could this be a hard disk problem which fsck can fix?
 
The discrepancy between df and du is well-documented. So stop shouting and drop to single-user mode. It's likely that the mountpoint of /var (which is a common directory) actually contains files that wound up there by mistake -- df detects and reports the space occupied by them, du does not. And fsck needs you to unmount /var anyway (yes, it may be some space allocated to a file descriptor that wasn't cleaned up), so that point is rather moot. Restarting services that use /var (e.g. syslog, mysql, and others) may clear that file descriptor, but if that fails, you'll have to drop to single-user mode.
 
First, calm down dude - running out of space is not the end of the world.

I ran into something like this recently - DD alluded to the cause. Say that a daemon writes out to a log file. If newsyslog rotates that log file, but the daemon doesn't respond to or understand the SIG_HUP signal that's sent to it by newsyslog to drop/reopen the log, it will continue writing to the original log file. Since this file is gone, it doesn't appear in your du output, but does consume space on your file system. If this continues, it'll eventually eat up all the space on /var

I haven't tried it, but I believe that simply rebooting the box (or restarting the offending daemon) will clear it up if this is indeed your problem. At least, it should temporarily, until the same thing happens again and the daemon starts sucking down space again.
 
You must log in or register to reply here.
Back
Top