I'm having a ubuntu server that is running out of disk space(36GB out of 37GB). I used several methods to check the disk usage, but sounds like the result is quite vague to me.

I used following commands for the checking, and the output is as this:

$ du -sh /*

6.2M    /bin
4.0K    /boot
20K     /dev
47M     /etc
2.1G    /home
72K     /include
27M     /lib
0       /lib64
4.0K    /media
4.0K    /mnt
546M    /opt
0       /proc
287M    /root
5.2M    /sbin
4.0K    /selinux
4.0K    /srv
0       /sys
59M     /tmp
2.7G    /usr
1.7G    /var

None of these seem to be anything close to 36GB, so I check like this:

$ df -h

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              38G   35G  835M  98% /
udev                   10M   20K   10M   1% /dev
none                  500M   16K  500M   1% /dev/shm
none                  500M   68K  500M   1% /var/run
none                  500M     0  500M   0% /var/lock

However I couldn't determine which directory used up most of the disk space. Can anybody give me a clue of how to check? Thanks.

  • Just to make sure, as there aren't any error messages in the du output: You run that command as root, right?! – mpy May 9 '13 at 16:01
  • @mpy: yes, I'm using root. – Shang Wang May 9 '13 at 16:35

I don't think that a "disk space visualization tool" can help you in this case: the space occupied and visible to such tools is the same visible to du, only those tools do it in more detail. But the tool would still report only those 8-10 GB that you already know are used, not report where are those twenty more gigabytes that are "missing in action".

A possible explanation for a "disappearing" space of such proportions is that it is in one (or more) deleted files.

If you open a file in Unix and, while still open, you delete (unlink) it, it will still "exist" but will only be visible to the process holding its file descriptor, and immediately disappear as soon as the process ends, releasing the descriptor.

This is a great way of managing temporary files.

Unfortunately, if the temp file leaks and data is continuously added to it, without ever closing and recreating the file, then lots of disk space may "disappear".

As root, try:

ls -la /proc/*/fd/* | grep deleted

The file names, and the process IDs, will tell you which processes are maintaining "unlinked" space.

If you can do it, of course, a reboot will have the same effect faster. And some processes are so entwined in the system that it's actually better to reboot them than to terminate them and manage all other depending processes and services.

For example on my machine I have about 25 such files, and this one

lrwx------ 1 root  root  64 May  9 07:45 /proc/732/fd/8 -> /tmp/vmware-root/vmware-usbarb-732.log (deleted)

I know that sometimes grows in the multi-megabyte range. Running

vmware-usbarbitrator --kill


can free anywhere from zero to 100M of space, depending how long it's been running and how much I have used vmplayer.

Automating the check

A way to check what files are hogging space would be to check their sizes: most unlinked files are only a few bytes.

This method uses wc, which is vastly inefficient; probably, opening the file, seeking to SEEK_END and returning the value of ftell() would be much, much quicker (especially on large files). But one would need to compile a small utility to do that.

for i in $( ls -la /proc/*/fd/* 2>/dev/null \
            | grep deleted \
            | sed -e 's/.*\(\/proc\S*\) -.*/\1/g' ); do
    wc -c $i | tr "\n" "="; readlink $i
done | grep -v "^0 " | sort -rn

This employs a (hopefully) portable way of listing the virtual fd's of all deleted files, and reads them with wc. Then, for each file, reads the symlink. Zero-length files are ignored to avoid clutter.

On my freshly-booted system this gives me

217032 /proc/812/fd/9=/var/run/nscd/dbMn7Auu (deleted)
217032 /proc/812/fd/8=/var/run/nscd/dbMn7Auu (deleted)
3278 /proc/2357/fd/3=/tmp/vmware-root/vmware-apploader-2327.log (deleted)
2257 /proc/2422/fd/7=/tmp/vmware-root/vmware-authdlauncher-2418.log (deleted)

so I know that nscd is availing itself of 400 Kb of "invisible space" (this does not change if I restart nscd; so it is probably a work area that does not grow... much. Nothing stops me from keeping tabs on the process, though).

It would be also easy to save the above code in a small utility and run it through cron, discarding all values under (say) 500 megs, but sending an email to the administrator should something pop up eventually.

  • An alternative to the ls /proc method would be lsof | grep deleted. – tink May 9 '13 at 18:39

You could try some tool that graphically represenst all the different files and folders on you system, and size them according to their disk usage. One such tool is 'xdiskusage'. See this link for more.


There are many different ways to do it in Linux. Check out the following answers:

How to understand what's taking up space.

Command line alternative to windirstat


Use Disk Usage Analyzer. It will display your memory usage graphically and you can dive down right to where you lost your memory. Great tool.

Note: to install, type sudo apt-get install baobab into terminal.

Here's a link with more info regarding your question: MakeUseOf - Analyze Disk Usage in Linux

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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