Full disk on server? How to track files with du and df

The storage exhaustion alert and server panic

Working with system administration on Linux servers inevitably brings us face to face with a dreaded warning message: the disk has become completely full. Applications crash abruptly, databases interrupt transactions due to lack of write space, and remote SSH access might even refuse new connections. In practice, this means the machine has lost the ability to write new data to physical storage, paralyzing essential services running on top of it. When the system reaches this critical threshold, the common first reaction is panic followed by random file deletions, which rarely solves the problem and can trigger even larger failures. To avoid this kind of drastic scenario, we need native tools capable of mapping exactly where space was consumed, uncovering the hidden villains that bloated our infrastructure. Just like a medical diagnosis needs precision before any surgical intervention, we must examine the filesystem methodically before hastily deleting important data, a workflow that relates directly to precautions we take when how to recover deleted files on Linux with TestDisk during accidental removals.

Understanding the macro view with the df command

The first step in investigating a storage issue is looking at the machine's big picture using the df command, which stands for disk free. In practice, this utility scans all active partitions and mount points on the operating system, showing total capacity, used space, occupancy percentage, and where each partition connects within the directory tree. To make the output human-friendly, we usually run the command accompanied by the -h flag, which converts raw block numbers into understandable units like gigabytes and megabytes. If you notice severe read and write bottlenecks associated with general system sluggishness, it is wise to cross-reference this analysis with guidelines on how to debug NVMe I/O bottlenecks on Linux. The basic usage of the command in your terminal can be executed as follows:

df -h

Upon executing this instruction, the screen will display a table divided into informative columns. The column named Filesystem points to the physical device or partition, Size shows total capacity, Used reveals occupied space, Avail indicates remaining available space, Use% shows exact usage percentage, and Mounted on reveals the root directory or mount point where that partition operates. If the row corresponding to the slash (the root directory /) is showing one hundred percent usage, we know precisely where the operational emergency lies.

Tracking top space consumers with du

Once you discover which filesystem is buried under data, the next logical step is finding out which specific folders are causing the bloat. For this surgical mission, we use the du command, short for disk usage, which recursively walks through system folders calculating the weight of each structure. Because large folders contain thousands of subdirectories, running the command without filters generates an endless stream of lines on the screen that does nothing to help quick diagnosis. To bypass this behavior and get a clean summary, we combine the command with smart parameters that limit search depth and sort results by size in descending order, a technique also very useful when cleaning up accumulations explained in How to Clean Docker Cache on Linux and Free Up Space. Here is how to inspect the current directory listing the largest folders:

du -h --max-depth=1 | sort -hr

In this command line, the -h flag preserves human readability for sizes, the --max-depth=1 argument restricts scanning strictly to the first level of subdirectories below the current folder, preventing the terminal from getting lost in deep sub-levels, and the sort -hr command organizes everything putting top consumers at the top of the list. By running this sequence inside the root folder, you will quickly isolate whether the problem is hidden inside directories like var, usr, or home, pointing your investigation to the exact trouble spot.

Investigating giant files and cleaning accumulated debris

With the perimeter closed around the problematic directory, we can navigate into it and repeat the search to isolate the exact file or subfolder consuming precious gigabytes. Often we encounter gigantic log files generated by applications that failed to rotate their activity records, or temporary files left behind by installers and background processes. If your machine uses traditional package managers, an excellent preventive and complementary practice is How to clear APT cache and free up space on Linux to recover valuable megabytes without risk. To list files and folders ordered by size inside a specific directory, we can use a robust combination of du with sorting tools:

du -ah --max-depth=1 /var/log/ | sort -hr | head -n 20

In this more advanced command, the -a flag instructs the utility to include individual files alongside directories, and the head -n 20 tool strictly limits output to the top twenty items found, saving precious operator time. When identifying a dead file or obsolete log that no longer holds operational utility, you can safely remove it via the rm command, immediately easing pressure on the operating system and reestablishing the server's safety margin.

A classic and very common mistake made by beginner administrators occurs when they remove large log files while applications are still writing to them, a scenario where disk space mysteriously fails to be freed after deletion. In practice, this happens because the running process maintains an open file descriptor in memory, forcing the operating system to keep physical blocks allocated until the process is fully restarted or the connection is closed. To track these silent ghosts that keep occupying space even after deletion commands, we can resort to kernel auditing utilities, a technique akin to what we use when analyzing memory faults in Container hanging? How to audit OOM Killer with dmesg. In these extreme cases, restarting the associated service or terminating the problematic process forces the system to definitively release idle storage blocks.

Final considerations on storage monitoring

Managing disk space on Linux servers goes far beyond deleting files manually when the disk-full alarm goes off in the middle of the night. By mastering the combined use of df commands for overview and du for surgical detailing, professionals gain autonomy and speed to diagnose any storage bottleneck before it turns into a service outage. Adopting periodic inspection routines, configuring automatic capacity limit alerts, and understanding process behavior regarding open files are fundamental pillars to maintaining a robust, stable infrastructure prepared for continuous business growth.