Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have run "df -kh" on my FreeBSD box and I see that /var is near 100% full. It was over but I have trimmed what I can but there is less then 500MB total on the partition according to running "du -ksh *" while in /var. The /var partition itself is 6.8G and it now says it only has 18M free. It just does not add up.

I run the following command I do not find any culprits.

 find . -type f -size +2000 -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'

I even drill down folder by folder using "du -ksh *" to identify the folders with lots of disk usage but I cannot find how it all adds up. I would like to compress, delete or move files in order to free up more space since the other partitions have space, but between df and du I cannot seem to find what is using all the disk space.

What else should I do to find the files and folders taking up all the space?

share|improve this question
    
What file system is /var? They don't all release delete file space immediately. Also, all files will get rounded to the nearest block size so ls won't report disk space used - for lots of small files this can add up. Do you have spare capacity to just create a bigger /var? –  Paul Jan 12 '12 at 0:27
    
du should still show the amount of disk usage accurately even if ls does not on an individual folder. If I could identify where the disk usage is so heavy I could remedy it. –  Brennan Stehling Jan 12 '12 at 1:23
    
Sure - provided your blocks are 1K du should work with those parameters. Any chance there is a .* file in the root of /var? –  Paul Jan 12 '12 at 2:22

3 Answers 3

up vote 1 down vote accepted

I'd run the following, so that you have a nice snapshot of all files to work with:

du -kx /var | sort -n | tee /var/tmp/du_results.out

... and then look at the last few hundred lines.

This will catch the size of all directories (to catch large numbers of small files), as well as catching ordinary large files. Note that I'm not using -h (human-readable), so that the results are easily sorted numerically. Note also that I'm not using /var/*, which would pick up anything mounted in /var as well.

The possible culprits include, in rough order of likelihood:

  • Stale unlinked files. Try what @not simon suggested (lsof /var). /var/tmp is sometimes an obvious place to find these. If you don't have lsof installed, you can use fstat -f /var | sort -k 8 -n, which doesn't show file names, but will at least show sizes (smallest to largest), inodes, and which process has the file open.

  • Filesystem corruption. Runfsck from single-user mode to check /var.

  • Old files hidden under mount points. If there are any mounts under /var, unmount them and then run your search/diagnostic again. The safest way to do this is probably to boot in single-user mode, and just mount /var without mounting anything under it.

Differences in file size reporting can be due to the presence of sparse or compressed files. You can use the -A option to du to work with apparent file size instead of disk usage, which might explain some discrepancies. Put it in and then leave it out, and compare the results. In my roughly 3.6Gb /var partition, results with -A were about 100Mb smaller.

share|improve this answer

Have you considered that you may have an unlinked file that is still open? Try looking over the output of lsof /var to see if there are any unusually large files listed.

share|improve this answer

I had a similar problem where a disk went away. The mount point still existed, but for some reason files were being written to the directory on the partition containing the mount point. This may not apply to your operating system, but booting a rescue system and perusing the partitions from there may reveal more.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.