Hi,

I've got a desktop where the df command shows my root partition is full but I can't find where the space is being used.

# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_dpgmsvm64-lv_root
50G 47G 189M 100% /
tmpfs 7.4G 3.7M 7.4G 1% /dev/shm
/dev/sda1 485M 36M 425M 8% /boot
/dev/mapper/vg_dpgmsvm64-lv_home
393G 13G 361G 4% /home


I ran a du to try and find where these 47 gigs (!!) are being used but get nothing really interesting... :

# du -xSh / | sort -n | tail -n 20
964K /usr/share/foomatic/db/source/PPD/Sharp
968K /usr/share/texmf/fonts/source/public/gothic
968K /usr/share/vim/vim72/lang
976K /usr/share/doc/postfix-2.6.6/README_FILES
984K /usr/lib/python2.6/site-packages/numpy/lib
988K /usr/share/icons/crystalsvg/16x16/actions
992K /usr/lib/vmware-installer/2.0/python/lib/lib-dynload
996K /usr/lib/python2.6/site-packages/M2Crypto
996K /usr/share/gnome/help/evolution/de/figures
996K /usr/share/texmf/tex/generic/babel
1000K /usr/lib/vmware-installer/2.0
1000K /usr/share/texmf/tex/latex/minitoc
1004K /usr/lib/perl5/auto/Encode/CN
1004K /usr/lib/perl5/auto/Encode/TW
1004K /usr/share/xml/iso-codes
1012K /usr/share/icons/oxygen/32x32/mimetypes
1012K /usr/share/man/man7
1016K /usr/share/icons/oxygen/64x64/apps
1020K /usr/share/emacs/23.1/lisp/international
1020K /usr/share/gutenprint/5.2/xml/escp2/model


Any ideas where to go from there?

Thanks!

you get nothing useful as you've the -h option, so you're numerically comparing "1020K" to "1.4G"... and 1020 is indeed a lot more than 1.4!

2 members found this post helpful.

Since /var is not a separate filesystem it is usually the first candidate to check. It contains /var/log which is where messages (system log) and other logs (e.g. mail logs) go. It also contains /var/tmp where some applications write their temporary files.

A common issue when there is disparity between du and df is that you've tried to delete (rm) an "open" file. When you do that only the name is deleted. The data in the inode is still present until the process that is holding the file "open" goes away. Often people will do something like "rm /var/log/messages" because they see that log taking up space but that log is being held "open" by syslogd (and sometimes other processes).

A simple way to clear such "open" file deletions is to reboot the system as it will stop all processes. However you don't have to reboot. You can run "lsof" and look for lines that have large numbers for size of CHR (character files) and see what process is associated. If it isn't showing you the file name it may be because you deleted the name so stopping and restarting such a process will clear the issue.

The -S option does not include subdirectories. In addition to what acid_kewpie said, exclude that and see what you get.

Hmm, in general I'd say it's more useful with it.

]# du -xb / | sort -n | tail -n 20
166160323 /usr/lib/vmware/isoimages
175506893 /usr/share/texmf
187129856 /var/tmp/kdecache-swoo/kpc
188027598 /usr/lib/openoffice.org/basis3.2/program
197500675 /var/tmp/kdecache-swoo
197508867 /var/tmp
211194060 /var/downloads/yum_updates/20120516-2
247425160 /var/downloads/yum_updates
252028777 /usr/share/icons
252223828 /var/downloads
272509306 /usr/lib/openoffice.org/basis3.2
281046298 /usr/bin
290484488 /usr/lib/openoffice.org
305034524 /usr/share/locale
540023635 /usr/lib/vmware
815169372 /var
1700358047 /usr/share
1996995188 /usr/lib
4081748393 /usr
5109184051 /

From this, I take it the / partition uses less than 5 GB... right?

@MensaWater: I did a reboot this morning but that didn't change anything

Try "du -sh /* | grep G"

@suicidaleggroll:
# du -sh /* | grep G
12G /home
du: cannot read directory `/proc/fs/vmblock/mountPoint': No such file or directory
du: cannot access `/proc/5360/task/5360/fd/4': No such file or directory
du: cannot access `/proc/5360/task/5360/fdinfo/4': No such file or directory
du: cannot access `/proc/5360/fd/4': No such file or directory
du: cannot access `/proc/5360/fdinfo/4': No such file or directory
4.1G /usr

That's it...

Well that's interesting. And df still shows 47G used in /?

@suicidaleggroll: yes it does...

What does "du -sxh /" show? What does "df -h /" show?

The former command should give you total usage for "/" as du sees it in "human readable" format restricting it only to the local filesystem / (ignoring submounts on /). df always shows you only whats in the filesystem ignoring other submounts on it.

If a reboot didn't free up anything you don't have the open file issue I mentioned. (Unless of course you deleted something after the reboot.)

What I typically do to try to narrow down where space is used is:

du -sk /* |sort -n

That will output a list of used files (mostly directories) in / from smallest to largest so the largest appear at end of list.

You'd ignore any submounts in that output (i.e. /boot and /home are submounts based on your earlier df output so you should ignore them for troubleshooting / space because they have their own space).

You can then drill down on whatever your largest item in the list is. So for example if /var were the largest you can run:

du -sk /var/* |sort -n

And keep drilling down successfully.

Again my first thought would be /var so I might start with "du -sk /var/* |sort -n" first THEN if I didn't find anything interesting there focus on the rest of /.

*MY* preference is usually to do something like

du -xh --max-depth=1 to get the size of only the first level of directories, and gradually dig deeper and deeper. easier to put the size of all the same level of directory into context I find.

Once I tried to delete "cache" directories in pursuit for a gig, but had to reinstall the whole system after.

*MY* preference is usually to do something like

du -xh --max-depth=1 to get the size of only the first level of directories, and gradually dig deeper and deeper. easier to put the size of all the same level of directory into context I find.