Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a centos webserver with the following partitions:

Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/md1      ext3     4956160   4697064      3272 100% /
/dev/md3      ext3     4956224   1192056   3508340  26% /var
/dev/md2      ext3   224524852  11572104 201363464   6% /home
/dev/md0      ext3       77649     23622     50018  33% /boot

I can't figure out why md1 is leaking space. Only 20 mins ago it read like below. Can anyone recommend a way of checking which file is getting larger/ taking up the space?

Filesystem    Type   1K-blocks      Used       Available Use%    Mounted on
/dev/md1      ext3   4956160        4696852    3484      100%    /


Do any of these look out of the ordinary?

12K     /aquota.user
7.8M    /bin
18M     /boot
204K    /dev
104M    /etc
12G     /home
312M    /lib
20M     /lib64
16K     /lost+found
8.0K    /media
0       /misc
8.0K    /mnt
0       /net
99M     /opt
0       /proc
110M    /root
32M     /sbin
8.0K    /selinux
208M    /sources
8.0K    /srv
0       /sys
84K     /tmp
2.7G    /usr
1.1G    /var
share|improve this question
You may also want to run this as root: "find / -mtime -1 -ls" . This will tell you the files edited within the last day, and their full filesize. – REW Nov 1 '10 at 15:58

No /tmp? Are you not showing the full list?

share|improve this answer

You can use the "du" command to see how much space is consumed by various directories. If you start at the top level and run something like this:

du -ks * | sort -n

This will sort directories and files from smallest to largest (displaying size in kilobytes). If it looks like most of the space is in one directory, cd to that directory and rerun the above command. Rinse and repeat until you find out where the files are.

There's always the possibility that this will fail because the space is being consumed by a file that is opened but has been deleted. You can use the lsof command to see which processes have open files on that filesystem.

share|improve this answer

I'd suggest starting with:

du -shx /*

That will show you the sizes of the directories in the root partition. Pick one that seems large (say /usr) and do:

du -shx /usr/*

Keep poking around until you find what's eating up your space. Be sure to use the -x flag so you are only looking at the root partition.

share|improve this answer

You show /tmp in the du output but not in the df output. If /tmp is on /, that will definitely fluctuate - and easily by the amount you're seeing.

If you can, get /tmp onto its own partition, even if you have to use tmpfs and effectively put it into core/swap. Other candidates for a rapid deportation from your (tiny!) root partition are /opt, most of whatever's taking up space in /root (though not /root itself), and /sources. Get those off into /home and soft-link them through.

Let me clarify that the underlying problem, to my mind, is the 5G root partition. There's no excuse for that, not on a machine with a 200GB HDD.

share|improve this answer

Your Answer


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.