Exercise 3: Confirming Genuine Disk Saturation in the Worked Example — Possible Solution
====================================================================

WHAT CONFIRMED GENUINE SATURATION, NOT JUST BUSY
------------------------------
Per this chapter, iostat reported "await at 85.40 ms - dramatically
above any of this chapter's reference points for either SSD or
spinning disk - alongside %util at 98.70%." Per the chapter's own
busy-vs-slow table, high %util combined with high await specifically
means "genuinely saturated... the clearest sign of a real bottleneck" -
distinct from high %util alone, which per Exercise 2's own reasoning
could just mean busy-but-healthy. It was the combination of both
figures being high - not %util by itself - that confirmed genuine
saturation.

WHY AWAIT ALONE WAS ALREADY A STRONG SIGNAL
------------------------------
85.40 ms is far above this chapter's own reference points (NVMe well
under 1ms, SATA SSD low single-digit ms, HDD 5-15ms) for any storage
type - even before combining it with %util, the latency figure alone
indicated something was taking far longer than normal to complete.

HOW iotop IDENTIFIED THE ACTUAL CAUSE
------------------------------
Per this chapter, "iotop immediately confirms the responsible process:
an rsync backup job writing at over 38 MB/s." Rather than inferring the
cause indirectly, iotop's per-process view showed the specific process
generating the disk activity directly - a backup job running well past
its usual overnight window and overlapping with business-hours
traffic.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies the combination of high await and high %util
(not either alone) as what confirmed genuine saturation per the
chapter's own table, and explains that iotop identified the cause
directly by showing the specific process's read/write activity rather
than requiring further inference.