0

my server root partition is full and I cannot seem to figure out what is taking up all space, my log files are at the very smallest. Any help on how to find what is eating up my space all of a sudden?

  • Do: sudo du -hxd 1 / as a first step. – muru Oct 22 '14 at 13:52
  • @muru yeah, I tried it but it was taking way too long. I finally narrowed it down to amavis virusmail folders which I emptied and everything went back to normal – chico ahmad Oct 22 '14 at 13:58

1 Answers1

2

There are a couple of ways to check this.

Before you start:

Make sure you won't be wasting your time on the methods I list by making sure that you don't have huge deleted files being held open by processes running on the machine:

mgodby@mg-ws1:~$ sudo lsof -s | grep deleted | less

Notes on this command:

  • This will open a less session on a list of deleted files that are still taking up space on your filesystem.
  • Refer to the 7th column to see the size of these files. Don't concern yourself with sizes that are less than 9 digits, as the sizes are in bytes.
  • Should you find any huge deleted files this way, end or restart whatever process is holding them open. Failing that, reboot.

File and directory size query methods:

To find normal undeleted files and directories that are taking up a lot of space on your system, try these 2 methods:

Method 1:

Drill down into directories layer by layer until you find the culprit. We can do this like so:

    mgodby@mg-ws1:~$ cd /
    mgodby@mg-ws1:/$ sudo du -xm -d 1 . | sort -n | tail -10
    1   ./srv
    1   ./tmp
    11  ./bin
    15  ./sbin
    25  ./etc
    385 ./opt
    684 ./lib
    1223    ./var
    4805    ./usr
    7145    .
    mgodby@mg-ws1:/$ cd usr
    mgodby@mg-ws1:/usr$ sudo du -xm -d 1 . | sort -n | tail -10
    1   ./games
    1   ./local
    21  ./sbin
    22  ./include
    219 ./src
    309 ./bin
    1431    ./share
    2806    ./lib
    4805    .
    mgodby@mg-ws1:/usr$ cd lib
    mgodby@mg-ws1:/usr/lib$ sudo du -xm -d 1 . | sort -n | tail -10
    87  ./firefox
    93  ./gcc
    123 ./vmware-ovftool
    126 ./python2.7
    180 ./jvm
    186 ./chromium-browser
    259 ./libreoffice
    74  ./vmware
    718 ./x86_64-linux-gnu
    2806    .
    mgodby@mg-ws1:/usr/lib$

You can repeat this process until you find whatever it is that is taking up the most space.

Notes about this method:

  • For command du, flag -m shows sizes in Megabytes, -x excludes results on other filesystems, and -d 1 changes the depth of the search to 1 layer.
  • sort -n simply numerically sorts the output.
  • tail -10 displays only the last 10 results, effectively ignoring all but the 10 largest results when coupled with sort -n
  • Alternatively to sudo du -xm -d 1 . | sort -n | tail -10, you can use sudo du -xh -d 1 . | sort -h | tail -10 to allow du to select the unit it thinks is best for the file or directory size. This is a matter of personal preference (thnx muru for the suggestion).

Method 2:

Query all files and directories on the filesystem at once and view the top results by size:

    mgodby@mg-ws1:~$ sudo du -xm / | sort -n | tail -50
    92  /usr/share/help
    93  /usr/lib/gcc
    93  /usr/lib/gcc/x86_64-linux-gnu
    96  /usr/src/linux-headers-3.16.0-22
    97  /usr/lib/chromium-browser/libs
    97  /usr/src/linux-headers-3.16.0-23
    98  /opt/openoffice4/share
    106 /usr/lib/python2.7/dist-packages
    113 /usr/share/doc
    123 /usr/lib/vmware-ovftool
    126 /usr/lib/python2.7
    137 /lib/modules/3.13.0-37-generic/kernel/drivers
    139 /var/lib/apt
    139 /var/lib/apt/lists
    143 /lib/modules/3.16.0-22-generic/kernel/drivers
    143 /lib/modules/3.16.0-23-generic/kernel/drivers
    165 /var/cache/apt-xapian-index
    165 /var/cache/apt-xapian-index/index.1
    180 /lib/modules/3.13.0-37-generic/kernel
    180 /usr/lib/jvm
    184 /lib/modules/3.13.0-37-generic
    186 /usr/lib/chromium-browser
    188 /lib/modules/3.16.0-22-generic/kernel
    188 /lib/modules/3.16.0-23-generic/kernel
    192 /lib/modules/3.16.0-22-generic
    192 /lib/modules/3.16.0-23-generic
    213 /usr/lib/libreoffice/program
    219 /usr/src
    259 /usr/lib/libreoffice
    264 /opt/openoffice4/program
    288 /usr/lib/vmware/modules/binary
    293 /usr/lib/vmware/modules
    309 /usr/bin
    321 /var/lib
    368 /usr/share/icons
    385 /opt
    385 /opt/openoffice4
    568 /lib/modules
    574 /usr/lib/vmware
    611 /var/cache/apt/archives
    684 /lib
    686 /var/cache/apt
    718 /usr/lib/x86_64-linux-gnu
    870 /var/cache
    1223    /var
    1431    /usr/share
    2806    /usr/lib
    4805    /usr
    7145    /
    mgodby@mg-ws1:~$ 

Notes about this method:

  • adjust -50 on tail -50 to give you the amount of results that you want, i.e. tail -30 for the top 30 results.
  • Alternatively, replace sudo du -xm / | sort -n with sudo du -xh / | sort -h to allow du to select the unit it thinks best for the file or directory size. This is a matter of personal preference (thnx muru for the suggestion).

Which method to use?

The results of method 2 may get you to a final answer more quickly than method 1 and give you more of a "big picture" kind of result, but method 1 is better-organized and easier to understand.

MGodby
  • 1,162
  • Suggestion: use -h instead of -m in du, then use the -h flag for sort instead of -n. – muru Oct 22 '14 at 15:08
  • That is an equally-valid way to do it and is really a matter of personal preference, I think. For me, I feel that the process goes faster when I can just glance at the numbers knowing that they are in Megabytes rather than having to mentally parse through multiple units. – MGodby Oct 22 '14 at 15:19
  • 1
    Will add that as an alternative in my answer, though. Thanks, @muru – MGodby Oct 22 '14 at 15:20