Why Deleting a File on Linux May Not Free Disk Space—and How to Fix It

On Linux, deleting a file with rm does not always immediately free the occupied disk space because the file may still be referenced by an open file descriptor. The article walks through creating a 50 MB random file in /boot using dd, monitoring space with df -h, and running a simple C program that opens the file and loops indefinitely.

Creating and Deleting the Test File

First, check the current mount usage, then generate the file:

$ dd if=/dev/urandom of=/boot/test.txt bs=50M count=1

After confirming the file appears, compile and run the program that opens /boot/test.txt and sleeps in a loop. Deleting the file with rm /boot/test.txt shows no change in df output because the process still holds the file open.

Stopping the program releases the file, and the space returns to the expected level.

When Is a File Actually Deleted?

A file is removed from the filesystem only when its reference count (including hard links) drops to zero. Opening a file increments this count; rm merely decrements it. If the count remains non‑zero, the inode and its data blocks stay on disk, allowing recovery of the data.

struct inode {
    unsigned long i_ino;   // inode number
    atomic_t    i_count;  // reference count
    unsigned int i_nlink; // hard link count
    /* other fields omitted */
};

Finding and Releasing Stale Open Files

Use lsof | grep deleted to list files that have been deleted but are still held open by processes. The article also shows inspecting a process’s file descriptors via /proc/$(pidof openFile)/fd, where entries ending with (deleted) indicate such files.

Practical Takeaways

Unclosed file handles, especially in long‑running services or log‑rotation scripts, can cause disk space to appear full even after files are removed. Always close file descriptors when they are no longer needed, and check for lingering open files with lsof if space does not recover.