Recently my disk space reached the 98% mark, and I tried to discover the reason for this. My system consists of two disks: a ssd /dev/sda and a storage hdd /dev/sdb.

My Linux is installed on /dev/sda2 and has 98% disk space left, and the hdd is mounted under /home. I tried to find the filesize under / with

du -h --max-depth=1 /

260M    /root
0       /proc
8,0K    /storageImage
598M    /opt
12K     /srv
0       /sys
84K     /dev
8,4G    /usr
35M     /boot
236G    /run                            
12K     /mnt                              
4,0K    /media                             
12K     /tmp                             
279G    /home                             
17M     /etc                              
642M    /var                              
16K     /lost+found                       
524G    /
524G    insgesamt

Only /usr has a significant size of ~9G. I use arch (systemd) therefore the huge run folder there is /media -> /run/media.

But df shows me this:

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda2        58G     54G  1,2G   98% /
dev             7,8G       0  7,8G    0% /dev
run             7,8G    796K  7,8G    1% /run
tmpfs           7,8G     32M  7,8G    1% /dev/shm
tmpfs           7,8G       0  7,8G    0% /sys/fs/cgroup
tmpfs           7,8G     24K  7,8G    1% /tmp
/dev/sdb1       362G    236G  108G   69% /home/dustin/opt
tmpfs           1,6G    8,0K  1,6G    1% /run/user/1000

Where is my disk space?

Edit: Thanks for the hint on Baobab. Other System but similar configuration


As one can see, there are 12G for /usr and 4G on /var that sums up to 16G but du says 49G.

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda6        64G     49G   12G   81% /
dev             3,9G       0  3,9G    0% /dev
run             3,9G    996K  3,9G    1% /run
tmpfs           3,9G    143M  3,7G    4% /dev/shm
tmpfs           3,9G       0  3,9G    0% /sys/fs/cgroup
tmpfs           3,9G    1,1M  3,9G    1% /tmp
/dev/sdb2       1,1T    716G  284G   72% /home/naikon/opt
tmpfs           784M     20K  784M    1% /run/user/1000

What consumes that 33G of disk space not found by baobab oder df? I can't use the "find" command as suggested. On / the screen is jammed with warnings.


The easiest way to find out would be:


To find the largest 10 files (linux/bash):

find . -type f -print0 | xargs -0 du | sort -n | tail -10 | cut -f2 | xargs -I{} du -sh {}

To find the largest 10 directories:

find . -type d -print0 | xargs -0 du | sort -n | tail -10 | cut -f2 | xargs -I{} du -sh {}

Only difference is -type {d:f}.

Source for the commandline


A bit simplified... Starting in ./ (replace with / to get system wide largest files)

find ./ -type f >FILES -printf "%016s %p\n" ; sort -rn FILES | head -n 50 

or if you do not wish to have the list FILES linger around... then:

find ./ -type f  -printf "%016s %p\n" | sort -rn | head -n 50
  • Seems like the >FILES belongs elsewhere? – Volker Siegel Sep 30 '14 at 18:40
  • Depends. If you wish to look into the list of files (FILES) in more depth, then the above is quite fine. – Hannu Oct 2 '14 at 21:03
  • I tried. Indeed, it behaves like a normal redirect at the end of the line - does it? Confused... How/why is it possible to have a redirect in the command line between args; and what is the advantage over having the redirect at the end of the line? (I assume the >FILE is not handled by find, right?) – Volker Siegel Oct 2 '14 at 21:11
  • Actually, these are nice questions to post; So let me just know whether I'm totally off... – Volker Siegel Oct 2 '14 at 21:13
  • In the first version ; makes things work as if you had entered two lines with Enter on each. – Hannu Oct 2 '14 at 21:14

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.