5

My disk space is dwindling by about 2GB a day! I only have a few more days before I run out of space. 

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda4             143G  126G   11G  93% /
udev                  491M  4.0K  491M   1% /dev
tmpfs                 200M  696K  199M   1% /run
none                  5.0M     0  5.0M   0% /run/lock
none                  499M  144K  499M   1% /run/shm
/dev/sda2             1.9G  580M  1.2G  33% /tmp
/dev/sda1              92M   29M   58M  33% /boot

I have been searching for the biggest directories/log files, deleting and compressing. But I am still losing the war. Finally, I realised I have a big misunderstanding:

julian@server1:~$ sudo du -h / | tail -n 1
16G     /

All of my files in / only add up to 16 GB. That leaves 110 GB unaccounted for!

Clearly I have a misunderstanding: I thought the '/dev/sda4' line represented all the files visible from '/'. What should I be reading to understand where the other storage has gone?

More details:

  • I have an Ubuntu 11.10 server, that was set-up by data-center staff.

  • It is running

    • my own code (which is fairly prolific with log files, but otherwise doesn't store much stuff on the drive)
    • duplicity for backups (which tends to store a lot of signature files)
    • various other standard services, like Apache, nagios, etc. They are very lightly used.

  • It has been up for about 4 months without a reboot.

  • I lied about the du output (simplified it for effect). It also complained about not being able to access GVFS and the du processes's own resources. I believe they are irrelevant:

.

 du: cannot access `/home/julian/.gvfs': Permission denied
 du: cannot access `/proc/10841/task/10841/fd/4': No such file or directory
 du: cannot access `/proc/10841/task/10841/fdinfo/4': No such file or directory
 du: cannot access `/proc/10841/fd/4': No such file or directory
 du: cannot access `/proc/10841/fdinfo/4': No such file or directory
Oddthinking
  • 351

1 Answers1

8

This may be caused by some application writing to an unlinked temporary file - such files will not show in du output (since they have no entries in any directory) but the application is still able to write to it so the file will grow and take up space.

You can use lsof +L command to find files which have hardlink count of zero and see which process owns the file. Restarting the process should free up the space.

See this answer for a slightly longer explanation

Community
  • 1
Sergey
  • 44,353