`df -h` and `df -i` read two different counters on the same mount, and only one of them was ever going to answer this failure. The notebook's own pairing line puts them next to each other: `paste <(df -h / | tail -1) <(df -i / | tail -1)` [23]. That is the fix, and it is one command longer than the investigation that already happened.
The successful probe file is the part worth studying. `touch ~/probe-ok.txt` returned clean, and the author took that as evidence the worker path was somehow special [5]. What it established is narrower: one write, in one directory, at one moment, found a free inode. For the stronger reading in the post, that a filesystem can accept a file in one directory and refuse a two-kilobyte file in another while blocks remain [6], either the two paths sit on different mounts or the last inode went between the two attempts. The notebook lists `mount | awk '{print $1, $3}'` among the commands run and never reports what it printed [17]. The mount question is exactly what a pre-blame sequence has to settle before a successful probe means anything.
The remediation failed in a mechanical way. Truncating with `: > worker.log` [7] keeps the directory entry and the inode and returns only blocks, so it recovers none of the resource that was exhausted [21]. The safe-delete helper went further: as reconstructed in the post it copies every JSON sidecar into `runs/.trash/` with no unlink [9], taking N files to 2N inodes while the byte cost stays as small as the files themselves [22]. Copying before deleting is a polite way to reach the ceiling twice as fast. The worker duly started failing sooner, sometimes on file four [10][11].
The lens was the problem before the cleanup was. Cache trees, `.pytest_cache` and editor swap files never surfaced in size-ranked output because thousands of small nodes do not look large [8]. The author did count files in `runs/` once, found the number bigger than expected but not millions, and went back to watching bytes, which he names as the first mistake he would not repeat [19]. His own summary is that bytes and inodes answer different questions and he had asked one of them [14], and that `du -sh` would not have shown this in a form he trusted at 2 a.m. [15].
Hour twenty of forty-eight is about 42 percent of the incident spent before the command that named the cause [20]. The author's verdict is that `df -i` should have been second, not twentieth [16]. That is the portion I would take: not a monitoring project, just a fixed second look on any ENOSPC where `df -h` reports calm.
What has to be true for this to transfer is modest, which is why an n of one is enough to change an ordering. The workload has to write many small files, and the mount has to be able to run out of inodes before it runs out of blocks. The author claims no benchmark and no quota promise, and labels his reproduction as a lab rather than an outage [18]. That is the right way to publish a field notebook. The evidence here supports the ordering rule; it says nothing about how full anyone else's inode table is.
