When administering Linux systems I often find myself struggling to track down the culprit after a partition goes full. I normally use du / | sort -nr but on a large filesystem this takes a long time before any results are returned.

Also, this is usually successful in highlighting the worst offender but I've often found myself resorting to du without the sort in more subtle cases and then had to trawl through the output.

I'd prefer a command line solution which relies on standard Linux commands since I have to administer quite a few systems and installing new software is a hassle (especially when out of disk space!)

  • 1
    @Bart thanks for taking the time to improve posts here, but may I ask you to take a little more care when adding tags? Tags aren’t for visibility, they describe the question. The disk tag isn’t appropriate here (see its tag description), and the at least two of the tags you added in this suggested edit weren’t appropriate there (Kali isn’t Debian, and there are no PPAs involved). – Stephen Kitt Jun 26 '19 at 10:02

37 Answers 37

1 2
du -sk ./* | sort -nr | \
awk 'BEGIN{ pref[1]="K"; pref[2]="M"; pref[3]="G";} \
     { total = total + $1; x = $1; y = 1; \
       while( x > 1024 ) { x = (x + 1023)/1024; y++; } \
       printf("%g%s\t%s\n",int(x*10)/10,pref[y],$2); } \
    END { y = 1; while( total > 1024 ) { total = (total + 1023)/1024; y++; } \
          printf("Total: %g%s\n",int(total*10)/10,pref[y]); }'



Still here? Or perhaps this answer has been upvoted...

While there are various graphical tools described in other answers, they don't do much to address the underlying issue of identifying how you may be able to free up space.

I am currently researching the same issue and came across agedu - which reports on access times as well as size. I've not had a chance to play with it yet - it's written by Simon Tatham (you may have heard of PuTTy) so is probably sensible/reliable.

However, like all the tools listed here, it collects data on demand. Even the most efficint coding on the fastests hardware will take time to walk a milt-terrabyte filesystem.

  • If you can't use a GUI (like you're on a remote server), ncdu -e works nicely. Once the display opens up, use m then M to display and sort by mtime, while the (admittedly small) percentage graph is still there to get you an idea of the size. – sitaram Aug 24 '19 at 12:53
  • "If you can't use a GUI (like you're on a remote server)," - why does a remote server prevent you from using a gui? – symcbean Aug 24 '19 at 16:02

I can't take credit for this, but I found it just yesterday:

$ find <path> -size +10000k -print0 | xargs -0 ls -l

link text


Here's the best method I've found:

cd /
find . -size +500000 -print

Identify the problematic filesystem and then use -xdev to only traverse that filesystem.


find / -xdev -size +500000 -ls

I realise that this thread is quite old, but nonetheless, very pertinent in any setup today and beyond. While all have offered excellent options to track down the disk hogs, what caught my attention was your statement "...I often find myself struggling...". It looks like you have to battle this symptom frequently. I would take a step back and see how you can prevent this. A precautionary measure will involve two steps:

  1. Alerting
  2. Action on the filesystem

As an example, when the FS hits 90%, you can set up an alert via Email to inform users about this situation. Or, you can Email yourself about it. A cron job can check the status at 5-min intervals.

Next, when it hits, say, 98%, you can run a script to set the FS readonly. This won't hurt much as it will go ro in a short while. But the advantage of setting an FS ro before 100% is that the user(s) can delete files when write is restored. While on this, there is a bug in some older versions of Solaris that will crash the system in the event of an FS hitting 100%, but we will leave it for another day.


The simplest is to change your current directory to / and execute :

du -chs / | sort -h
  • 1
    Using du -s means this will print a total size for / and nothing else. – sourcejedi Jun 7 '17 at 7:24
1 2