Terminal.Drill Get the app
ch05/l03

CPU, memory, disk, and inode first pass

Separate resource symptoms before choosing a fix.

df -hi 25 min read, 35 min lab operator

Linux performance triage starts with resource classes: CPU/load, memory pressure, disk bytes, inodes, and I/O. Low `free` memory is not automatically bad because Linux uses cache; `available` memory matters more.

In the field

An app says 'No space left on device' but `df -h` looks fine.

Worked command

$ uptime$ free -h$ df -h$ df -hi$ du -sh /var/log/* | sort -h
Anti-pattern

Do not restart services before proving the resource constraint.

Safer pattern

Check bytes and inodes, then directory usage, then process-level clues.

Knowledge check

An app reports 'No space left on device' but `df -h` shows plenty of free space. What is the most likely cause and the check that confirms it?

  • A The disk is failing; confirm with another df -h run
  • B Memory is exhausted; confirm with free -h showing low available
  • C Inodes are exhausted even though bytes are free; confirm with df -hi
  • D The filesystem is read-only; df -h would already prove that
Show the answer

Correct: C. Inodes are exhausted even though bytes are free; confirm with df -hi

Why

A filesystem can run out of inodes (file slots) while bytes remain free — common with many tiny files — and only df -hi exposes that, since df -h reports bytes only. Low available memory is a different symptom and would not produce a per-filesystem 'No space left on device' error.

Practice checklist

  1. Run read-only capacity checks on a workstation or sample output.
  2. Explain whether bytes, inodes, or memory look constrained.
  3. Name the next safe check.

Deliverable evidence

  • A resource triage table with command, observation, and conclusion.
Teaching diagramch05 · mental model
symptom -> evidence -> least-invasive action symptom slow / full / stuck which class? CPU mem disk inode uptime CPU / load free -h available mem df -h disk bytes df -hi inodes narrow it: du -sh, pgrep -a, ps aux name the busy process or constraint TERM before KILL, only after evidence no blind restart

shows: The triage path: a symptom sorts into a resource class (CPU, memory, disk bytes, inodes), each with its own first command, then narrows to a named process or constraint before any TERM/KILL or restart.

does not prove: It shows the order of checks, not the verdict: running these commands gathers evidence but does not by itself prove which resource is the true bottleneck — you still have to read the numbers and reason about available vs free, bytes vs inodes.

Memorize this

Commit these to memory, then drill them until recall is automatic.

uptimefree -hdf -hdf -hidu -sh

Reference

free -hdf -hidu -sh
Recall practice · Failure -> diagnostic

cue 'No space left on device' but byte usage looks fine — expose inode exhaustion

show recall target

df -hi

See this drill type Practice recall in the app