Monitor Disk Space and Inodes

What you will be able to do

• Explain the five core decisions involved in monitor disk space and inodes.
• Choose the narrow Linux command or method that matches a stated operational need.
• Interpret command output as evidence before deciding whether to change system state.
• Apply an observe, act, verify, and recover workflow to a realistic Linux task.

01

Build the Operating Model

Compare filesystem capacity, inode availability, directory use, and open-file behavior to diagnose storage pressure accurately.

Reliable Linux work separates observation, decision, action, and verification. That order keeps a command from becoming a guess and makes each result useful for the next decision.

Begin in a disposable lab or a recoverable environment. Record the active user, working directory, target, and baseline output before any command that can change system state.

02

Filesystem capacity

The `df` command reports allocated, available, and used space for mounted filesystems rather than individual directory totals. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Query the path experiencing the problem and identify the exact mounted filesystem that contains it. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: human-readable rounding can hide small differences. You should be able to verify this result: capacity and free space for one filesystem.

03

Inode capacity

A filesystem can exhaust its inode supply even when data blocks still appear available. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Check inode percentages when new files cannot be created despite apparently sufficient byte capacity. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: many tiny files can exhaust inodes. You should be able to verify this result: used and available inode counts are visible.

04

Directory usage

The `du` command totals space attributed to selected files and directory trees at the time of traversal. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Measure the broad directory, then descend into the largest immediate children instead of scanning everything repeatedly. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: permission errors can make totals incomplete. You should be able to verify this result: large directory trees are ranked by use.

05

Deleted open files

A removed file can continue consuming filesystem space while a process still holds it open. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Compare directory totals with filesystem use and inspect open deleted files when the numbers do not reconcile. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: restarting a process can interrupt its service. You should be able to verify this result: hidden use held by a process is identified.

06

Cleanup evidence

A safe cleanup links a measured source of pressure to a reviewed retention or deletion action and a measured result. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Record the baseline, remove only approved data, and repeat both capacity and directory measurements. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: do not delete logs before preserving needed evidence. You should be able to verify this result: freed space is confirmed on the correct filesystem.

07

Apply One Controlled Change

Start from the read-only commands that reveal identity, scope, and current state. Write the expected result before entering a modifying command, including which files, processes, accounts, or connections may be affected.

Make one narrow change and stop. If the output reports an error or an unexpected target, preserve that evidence and return to inspection instead of adding unrelated commands.

Repeat the original observation after the action. A successful command status is useful, but the real completion signal is the intended state plus the absence of an unintended side effect.

08

Complete the Evidence Loop

A good terminal record answers four questions: what was observed, why one action was selected, exactly what changed, and how the result was verified. A screenshot without command context answers fewer questions than saved text output.

Test both the expected success and one safe failure condition. This confirms that the procedure recognizes a wrong path, missing permission, invalid input, stopped service, or unavailable endpoint instead of silently continuing.

Finish by restoring the lab baseline when the task was experimental. For an operational change, record the final state and the reversal step so later work begins from a known boundary.

09

Recap Before Practice and Prove

The first decision concerns filesystem capacity. Query the path experiencing the problem and identify the exact mounted filesystem that contains it.

The second decision concerns inode capacity. Check inode percentages when new files cannot be created despite apparently sufficient byte capacity.

The third decision concerns directory usage. Measure the broad directory, then descend into the largest immediate children instead of scanning everything repeatedly.

The fourth decision concerns deleted open files. Compare directory totals with filesystem use and inspect open deleted files when the numbers do not reconcile.

The final decision concerns cleanup evidence. Record the baseline, remove only approved data, and repeat both capacity and directory measurements. Keep the final output as the baseline for the next task.