Storage & Filesystems

Deleted files still occupy disk space

Explain df and du disagreement by locating deleted files still held open by processes, then release their handles without corrupting application state.

On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • Deleting a large log does not restore expected free space.
  • lsof shows a large file with link count zero still open.

Relevant environment

Local filesystems where a service or application keeps an unlinked file open; snapshot retention is a separate mechanism.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • Unlinking a file removes its name, but open file descriptors keep its inode and blocks alive until closed.
  • Hidden mounted directories, snapshots or allocation accounting can also explain df/du differences if no large deleted handle exists.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read open files with link count below one system-wide; administrator rights allow inspecting other users’ processes.

sudo lsof +L1

Interpret the result: Large regular files marked deleted identify potential retained blocks and the owning PID. Sparse size and multiple descriptors can exaggerate simple summed totals.

Check 2

Replace /affected/path with an existing path on the filesystem holding the deleted file.

df -h /affected/path

Interpret the result: Recheck this same filesystem after a handle closes. A df/du gap is a clue, not proof; metadata and reserved space also consume blocks.

Evidence-guided next steps

Ask the owning service to reopen its log

If the deleted file is a service log and the service documents a log-reopen signal or reload action, use that documented action during an appropriate window. Verify the PID no longer holds the deleted file.

Precautions: A generic HUP is not safe for every process; it may terminate an application. Preserve any log content needed for investigation before releasing the handle.

Recovery / rollback: Restore the service’s prior logging configuration if reopening fails; restart it through its normal supervisor when necessary.

Did this solution help you?

Share this solution#

Close the owning application cleanly

If the process has no supported reopen function, save its work and close or restart only that application or service. Closing the last descriptor releases the unlinked file’s space.

Precautions: Plan downtime for stateful services. Do not truncate arbitrary /proc/PID/fd handles; they may be database files or active application data.

Recovery / rollback: Reopen the application and validate saved state; recover required removed content from the preserved copy or backup.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.