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
can free anywhere from zero to 100M of space, depending how long it's been running and how much I have used
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.