You log into your server and the first thing you see is a warning from your monitoring tool: disk usage on the root partition just crossed 95 percent. Worse, it is climbing. Within minutes you could hit 100 percent and watch services start failing, logs stop writing, and databases reject inserts. This is the moment every Linux administrator dreads, and the question that immediately follows is always the same: what is filling up the disk?
The good news is that Linux gives you a small set of sharp tools to answer that question fast. The du command is the centerpiece of any Linux disk du process investigation because it tells you exactly how much space each directory and file consumes. Pair it with ncdu for a visual interface, df for a filesystem-level overview, and lsof to connect usage back to the actual process doing the writing, and you have a complete diagnostic workflow.
In this guide I will walk you through that workflow step by step. By the end you will know how to find the largest files and directories, narrow down to the single process responsible, and clean up the mess without breaking anything along the way. Everything here uses commands available on any modern Linux distribution, no extra software required beyond ncdu for the interactive section.
Table of Contents
Understanding the du Command and What It Reports
The du command (short for “disk usage”) estimates how much storage a specific file or directory tree occupies on disk. It walks the filesystem recursively, sums up block sizes, and reports the total. When a server disk is filling up and you need to trace it back to a directory, du is the first tool I reach for because it gives you a number you can act on immediately.
It is easy to confuse du with df, so let me draw a clear line before we go further. df reports the total, used, and available space at the filesystem and mount-point level. Think of df as the fuel gauge on your dashboard: it tells you the tank is low but not which cylinder is burning too much. du is the mechanic’s diagnostic that shows consumption per directory and per file. For any Linux disk du process investigation you need both, and I will show you exactly when to switch between them.
One more thing worth knowing up front: du measures actual disk blocks, not apparent file sizes. That means sparse files and filesystem compression can make the du number smaller than the byte count a file manager shows. If you ever see du and ls -l disagree wildly, that gap is usually why.
du Command Basics Every Linux User Should Know
The du command ships with a handful of flags that completely change what you see. Master these four and you can diagnose almost any disk problem from the terminal in seconds.
du -h for Human-Readable Output
By default, du prints sizes in 1024-byte blocks with no units. That is unreadable for anyone who does not convert block counts in their head. The -h (or --human-readable) flag converts those numbers into kilobytes, megabytes, and gigabytes automatically.
du -h /var shows each subdirectory of /var with a clean, human-readable size like 4.2G or 512M. I run this on almost every server I touch because the raw output without -h is nearly useless for quick triage.
du -s for a Summary Total
When you only want the grand total for a directory and not a recursive listing of every subdirectory, add the -s (or --summarize) flag. This is perfect for comparing the overall size of a few top-level directories without scrolling through hundreds of lines.
For example, du -sh /var /home /tmp /opt prints one line per directory, each showing the total size. That single command has saved me hours over the years because it instantly reveals which top-level directory is the culprit.
du -a to List Individual Files
The -a (or --all) flag tells du to report every file, not just directories. This matters when a single large log file or database dump is the problem and its parent directory is otherwise small. Combine it with -h and pipe through sort to surface the largest files instantly.
Run du -ah /var/log | sort -rh | head -20 and you get the 20 biggest files in your log directory, sorted largest first. That is usually the exact answer you are looking for.
Common Useful du Flags
A few more flags earn a permanent spot in my toolkit. -x (or --one-file-system) prevents du from crossing filesystem boundaries, which keeps virtual filesystems like /proc and /dev out of your results. --max-depth=N limits recursion to N levels, great for keeping output manageable. --threshold=SIZE filters out anything smaller than the size you specify, so you can ignore tiny files that are not the problem. And --time appends a last-modified timestamp, which is invaluable when you suspect a process started writing a large file at a specific moment.
Finding the Largest Files and Directories with du and sort
The real power of du comes from combining it with sort. The classic one-liner for any Linux disk du process investigation is du -ahx / | sort -rh | head -30. Let me break down why that combination works so well.
The -a flag lists every file, -h makes the sizes readable, and -x keeps you on a single filesystem. Piping the result through sort -rh sorts by human-readable size in descending order, so the biggest consumers float to the top. Tacking on head -30 limits the output to the 30 largest items, which is usually enough to spot the problem.
Limiting Depth to Stay Sane
On a large filesystem, a full recursive du can take minutes and produce thousands of lines. Use --max-depth=1 to get a top-level breakdown first, identify the offending directory, then drill into that directory with another du call. This iterative approach is faster and far easier to read than dumping everything at once.
A typical first pass looks like sudo du -h --max-depth=1 /var | sort -rh | head -15. You spot that /var/log is 18 GB, then run sudo du -ah /var/log | sort -rh | head -15 to find the specific log file blowing up. Two commands, two seconds, answer found.
Filtering with –threshold
The --threshold flag is underrated. Add --threshold=100M and du only reports entries larger than 100 megabytes. On a busy server with millions of tiny files, this flag is the difference between a useful short list and a wall of noise. I use it constantly when I already know the problem is a large file and I just need its name.
Using ncdu for Interactive Disk Analysis
The ncdu tool (NCurses Disk Usage) wraps the du engine in a full-screen, keyboard-navigable interface. If you have ever been frustrated trying to read pages of du output, ncdu is the upgrade you wish you had installed years ago. Forum users on r/linuxquestions recommend it constantly, and for good reason.
Installing ncdu
On Debian and Ubuntu, run sudo apt install ncdu. On RHEL and Fedora, use sudo dnf install ncdu. On Arch, it is available through sudo pacman -S ncdu. The install takes seconds and the binary is tiny.
If you cannot install packages on the server, download a static ncdu binary from the project’s releases page and run it directly. I keep a copy in my home directory on locked-down production boxes specifically for this purpose.
Navigating the ncdu Interface
Launch it with ncdu /var and it scans that directory, then presents a sorted list of subdirectories and files with their sizes and percentage of the parent. Use the arrow keys to move up and down, Enter to descend into a directory, and d to delete a selected file or directory directly from the interface.
The percentage column is the killer feature for me. It instantly shows which subdirectory eats 80 percent of its parent, letting you follow the space trail downward with three or four keystrokes instead of retyping du commands. Press q to quit and ? for the full keybinding list.
When ncdu Beats Raw du
Use ncdu whenever you are exploring unfamiliar territory and do not yet know which directory to target. Use raw du with sort when you already know the directory and just need the top N files piped into a script or report. For a deeper alternative, gdu is a faster Go-based tool that supports -x for single-filesystem scans and handles SSD storage much faster than ncdu on large trees.
Using lsof to Find Which Process Is Writing to Disk
Here is the gap that almost no competitor article covers: du tells you which directory is large, but it does not tell you which process is actively writing to it. If your disk fills up by a gigabyte every few minutes, finding the directory is only half the battle. You also need to identify the process behind the growth, and that is where lsof comes in.
The lsof command (list open files) shows every file currently held open by a running process. Since Linux treats almost everything as a file, including network sockets and devices, lsof gives you a direct line from disk activity to the process responsible. This is the missing link in most Linux disk du process guides.
lsof Basics for Disk Investigation
Run sudo lsof +D /var/log to list every process with an open file handle inside /var/log. The +D flag recursively scans the directory you specify. Each line of output shows the process name, PID, user, file descriptor, size, and full path. If a log file is growing rapidly, you will see the logging daemon or application holding it open right here.
For a broader view, sudo lsof / | grep -i log filters all open files on the root filesystem down to anything with “log” in the path. That is how I caught a misconfigured application writing a 40 GB debug log to /tmp on a client’s server last year.
Tracking Deleted Files That Still Hold Space
This is the scenario that trips up almost every administrator at least once: you delete a large log file with rm, but df still shows the disk as full. The reason is that a running process still has the file open. Linux keeps the inode allocated until the last file descriptor closes, so the space is not actually freed even though the filename is gone.
Find these phantom files with sudo lsof +L1. The +L1 flag lists files with a link count below 1, meaning they have been deleted from the filesystem but are still held open by a process. The output shows you the PID, so you can restart or signal that process to release the space. I have seen this single command recover 50 GB of “lost” disk space in production.
Linking lsof Output Back to du
The workflow is simple once you see it in action. Use du to find the large directory, use lsof +D on that directory to see which processes have files open inside it, then investigate or restart those processes. If du shows a directory is huge but you cannot find the files with ls, switch to lsof +L1 to check for deleted-but-open files consuming the space invisibly.
Step-by-Step Workflow for Diagnosing a Full Disk
Let me give you the exact sequence I run when a monitoring alert fires. This is the workflow that ties every tool together into a repeatable process.
Step 1: Check the filesystem overview with df -h. This confirms which filesystem is actually full and shows the total, used, and available space. If multiple filesystems are involved, note which one triggered the alert.
Step 2: Check inode usage with df -i. A disk can run out of inodes before it runs out of bytes, especially on servers with millions of tiny session or cache files. If df -h looks fine but writes still fail, an inode shortage is the likely culprit.
Step 3: Drill down with du. Run sudo du -h --max-depth=1 / | sort -rh | head -15 to find the largest top-level directory. Then descend into that directory and repeat until you reach the specific file or subdirectory consuming the space.
Step 4: Switch to ncdu if the tree is complex. When the directory structure is deep or unfamiliar, launch ncdu on the target directory and navigate visually. The percentage column guides you straight to the problem in seconds.
Step 5: Identify the process with lsof. Once you know which directory or file is growing, run sudo lsof +D /path/to/dir to see which process holds files open there. If the file was deleted but space was not freed, use sudo lsof +L1 to find it.
Step 6: Clean up safely. Stop or restart the offending process if appropriate, then remove or rotate the large files. For log files, use truncate -s 0 filename instead of rm if the process still has the file open, because truncating frees the space immediately without requiring a process restart.
Step 7: Verify with df -h again. Confirm the space was actually reclaimed. If df still shows the disk as full after cleanup, loop back to Step 5 and check for deleted-but-open files.
Comparing du and df for a Complete Disk Picture
You will sometimes see du and df disagree about how much disk space is in use, and understanding why is essential for accurate diagnosis. df reads the filesystem superblock, so it reports the true amount of allocated space at the kernel level. du walks the directory tree, so it only counts files it can see through the normal filesystem namespace.
When df says the disk is 100 percent full but du only accounts for a fraction of that space, the gap almost always comes from one of three causes. First, a deleted file is still held open by a running process, which we covered with lsof +L1. Second, a file is hidden under a mount point, meaning a large file existed before a filesystem was mounted on top of it. Third, reserved blocks for the root user are counted by df but not visible to du running as a normal user.
Inode Exhaustion vs Space Exhaustion
Run df -i alongside df -h on every investigation. If df -i shows 100 percent inode usage but df -h shows plenty of free bytes, you have an inode problem, not a space problem. The fix is different: you need to delete many small files, not one large one. Use sudo find /var -xdev -printf '%hn' | cut -d/ -f-4 | sort | uniq -c | sort -rh | head -20 to find directories with the highest file counts, then clean out the offenders.
I encountered this exact scenario on a mail server where a spam flood created 12 million tiny queue files. df -h showed 60 percent free, but the filesystem rejected every new file creation because inodes were exhausted. df -i caught it instantly, and purging the queue solved the problem in minutes.
Frequently Asked Questions
How do I find out what process is using a directory in Linux?
Run sudo lsof +D /path/to/directory to list every process with an open file handle inside that directory. The output shows the process name, PID, user, and file path, so you can identify and investigate the process responsible for disk activity.
How do you see what process is using disk Linux?
Use sudo lsof +L1 to find deleted files still held open by processes, and use sudo iotop or sudo pidstat -d 1 to monitor real-time disk write activity per process. Combining lsof for open-file tracking with iotop for live writes gives you a complete picture of disk-using processes.
How do I find out what is taking up disk space in Linux?
Run df -h to see which filesystem is full, then run sudo du -h u002du002dmax-depth=1 / | sort -rh | head -15 to find the largest top-level directory. Descend into that directory and repeat the du command, or use ncdu for an interactive view, until you reach the specific files consuming the space.
How to check du command in Linux?
Open a terminal and run du -sh /path/to/directory to get the total size of a directory in human-readable format. Add the -a flag to list individual files, the -h flag for readable sizes, the -s flag for a summary, and pipe through sort -rh to sort results from largest to smallest.
Conclusion
Diagnosing a full Linux disk comes down to a simple four-tool workflow: start with df -h and df -i for the filesystem overview, drill in with du and sort to find the largest directories and files, switch to ncdu when you need a visual map, and finish with lsof to connect the space back to the process writing it. That is the complete Linux disk du process methodology I use on every server I administer, and it has never failed to pinpoint the problem quickly.
The next time your monitoring fires a disk-full alert, resist the urge to panic-delete files. Run through the seven-step workflow above methodically. You will find the culprit directory in minutes and the responsible process shortly after, and you will fix the root cause instead of just papering over the symptom. Keep ncdu installed on every server you manage, and bookmark the lsof +L1 command for the inevitable day a deleted file refuses to release its space.