Exercise 1: Why du and df Can Disagree — Possible Solution ==================================================================== WHAT CAUSES THE MISMATCH ------------------------------ Per this chapter's finding-box, "when a file is deleted while a running process still has it open, Linux doesn't actually reclaim the space - the space is only freed once every process holding it closed has released it." The file still occupies real, allocated disk blocks even though it no longer has a name. WHY du DOESN'T SEE IT ------------------------------ Per this chapter, "du walks the visible directory tree by name, and a deleted file has no name left to walk to, so it's invisible to du entirely." Since du's method of counting space is to traverse directory entries, a file with no directory entry at all simply cannot be found or counted by it, regardless of how much space it still occupies. WHY df STILL COUNTS IT ------------------------------ Per this chapter, "df, which reports actual block-level usage, still counts it." df doesn't care about filenames or directory structure - it reports how many blocks on the underlying filesystem are actually allocated, and a deleted-but-open file's blocks remain allocated regardless of whether any name points to them. WHY THIS PRODUCES A REAL, MEANINGFUL GAP ------------------------------ Per this chapter, "the gap between the two totals is real, allocated disk space, held open by a process, with no visible trace in the filesystem tree at all." The mismatch isn't a bug in either tool - both are accurately reporting what they're each designed to measure; the difference between those two measurements is what reveals the deleted-but-open file. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains the underlying Linux behavior (space not freed until every open handle closes), and separately explains why each tool's own measurement method causes it to either see or miss that space, rather than describing the mismatch as unexplained or as a tool malfunction.