## Scenario A Linux host reports that a filesystem is almost full in `df`, but a recursive `du` scan of the apparent mount contents reports much less usage. Explain what each command measures, identify credible causes of the gap, and give a safe investigation sequence that does not make the incident worse. ### Constraints & Assumptions - The filesystem may be serving production traffic. - You may inspect processes, mounts, inodes, and filesystem metadata, but should not kill processes or delete files before identifying ownership and recovery impact. - Distinguish block exhaustion from inode exhaustion. ### Clarifying Questions to Ask - Are both commands examining the same mounted filesystem and namespace? - Is the discrepancy in used blocks, available blocks, or inode counts? - Did a large file recently rotate or get deleted while its process remained alive? - Are snapshots, reserved blocks, sparse files, hard links, or nested mounts relevant to this filesystem type? ```hint Compare allocation views `df` asks the filesystem for allocation totals; `du` walks reachable directory entries and sums file usage. Look for allocated blocks that the walk cannot see. ``` ### What a Strong Answer Covers - The different data sources behind `df` and `du`. - Deleted-but-open files, mount-namespace differences, nested mounts, reserved space, snapshots, sparse files, hard links, and metadata overhead. - Commands such as `findmnt`, `du -x`, `df -i`, and `lsof +L1`, used with attention to permissions and namespaces. - A remediation plan that coordinates with the owning service and verifies reclaimed space. ### Follow-up Questions 1. Why can restarting the correct process reclaim space that deleting more paths cannot? 2. How can a container's mount namespace make a host-side scan misleading? 3. What would you inspect when blocks are available but file creation still fails?