Why removing a name may not release allocation
Deleting a directory entry and closing a file are different events. A process can keep an unlinked file open, so an ordinary directory walk no longer finds its name while the filesystem still accounts for its allocation. This is one possible reason that df and du disagree, not a diagnosis to assume from every difference.
For a beginner, imagine that the application still holds a reference to an object whose public label has been removed. The immediate question is which process holds that reference and what a safe close means for its work. Killing whichever process looks largest skips that operational question.
Setup: compare the same filesystem and access scope
Record the exact mount and the commands used for both measurements. A recursive directory estimate can omit inaccessible directories, cross into another mount, or observe a changing workload. GNU's Coreutils FAQ explains why filesystem totals and directory totals describe different things. Review scan errors before concluding that space is invisible.
On supported local filesystems, lsof +L1 selects open files with a link count below one. Limit collection to the affected host or filesystem where practical, and use appropriate diagnostic privileges to avoid silently missing another user's processes. Names and size fields can vary by platform and file type; consult the installed lsof manual.
Illustrative incident: manual log deletion keeps the writer attached
An illustrative operator removes a growing log file while its service continues writing through the existing descriptor. The pathname disappears, but the capacity alert remains. This example is educational and does not describe a client engagement or prove a particular amount of recoverable space.
Correlate the process identifier, file descriptor, device and link count with the application's documented log handling. Process identifiers can be reused, so recheck ownership before action. Several descriptors or processes may refer to the same underlying file; summing every displayed size can overstate the allocation that a single close would release.
Troubleshooting: keep the evidence specific
| Observation | Evidence | Next decision |
|---|---|---|
| Large filesystem-directory gap | Matching mount and complete scan | Exclude scope and permission differences |
| Unlinked regular file remains open | Device, descriptor and live process | Identify its purpose and owner |
| File is an active application log | Supported reopen or rotation mechanism | Prefer the application's documented lifecycle |
| No relevant open file is found | Filesystem type and allocation features | Investigate other explanations rather than forcing this diagnosis |
Network filesystems and copy-on-write storage have additional accounting behavior. This runbook does not treat lsof output as a universal physical-storage inventory. Preserve enough evidence to let a storage specialist distinguish an open handle from snapshots, reserved capacity or another allocation boundary.
Correct the writer's lifecycle
Use the documented log-reopen operation when the application supports one, or plan a controlled restart after checking in-flight work and service redundancy. An application that stores temporary business data may need a different recovery path from a log writer. Never truncate an arbitrary descriptor merely because an internet example suggests doing so.
Repair log rotation so future generations are handed off correctly. Confirm the expected destination, ownership and reopen behavior with the service team. A capacity action is incomplete when the writer simply recreates the same unbounded growth pattern after restart.
Verify space and operational continuity
Recheck the specific descriptor and filesystem allocation after the approved close. Verify that fresh logs arrive at the intended location and that a representative application request succeeds. If allocation does not fall as expected, re-examine remaining holders and filesystem accounting instead of repeatedly restarting unrelated services.
The monitoring objective should cover useful logging and storage headroom together. An internal SLO might track successful work while capacity recovery is underway; contractual availability belongs in a separately agreed SLA. The SOP should record diagnostic scope, process-owner approval, supported reopen method, restart impact and recovery evidence. Keep log-retention and incident-preservation duties explicit.
See Clouvenix linux administration for help defining a reviewed operational scope.
Technical reference
GNU df versus du FAQ, lsof unlinked-file FAQ, lsof diagnostic tutorial. Reviewed 19 October 2026; select documentation matching the installed release.