Exercise 2: Why lsof +L1 Is the Right Tool for This Mismatch — Possible Solution
====================================================================

WHAT lsof +L1 SPECIFICALLY LOOKS FOR
------------------------------
Per this chapter, "lsof +L1 lists open files with a link count of 0 -
files that have been deleted but are still held open by a running
process." A link count of 0 means the file has no directory entries
(names) pointing to it anymore - exactly the state of a deleted file
that a process still has open.

WHY THIS IS EXACTLY THE RIGHT TOOL FOR THE MISMATCH
------------------------------
The df/du mismatch, per this chapter, is caused specifically by
deleted-but-still-open files - space df counts but du can't see because
it has no name to walk to. lsof +L1's own filter (link count of 0)
targets precisely that category of file: something with no visible
name in the filesystem (which is why du misses it) but still occupying
real space through an open file handle (which is why df counts it).

WHY A GENERAL lsof OR du SEARCH WOULDN'T WORK AS WELL
------------------------------
A plain du search only sees named files, so it can never find a
deleted file by definition - no matter how the du command is run.
Running lsof without the +L1 filter would list every open file on the
system, most of which are completely normal and irrelevant, making it
far harder to spot the specific deleted-but-open files responsible for
the missing space.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states the specific technical meaning of "link count of 0," and
explains precisely why that criterion matches the exact category of
file responsible for the df/du gap, rather than describing lsof +L1 as
simply "a tool for finding the problem" without connecting it to the
underlying cause.