Operations 7 min read

Why Deleting a File with rm May Not Free Disk Space – Understanding Inode References

This article explains why removing a file with rm on Linux sometimes leaves disk space unchanged, demonstrates the behavior with a random file and a C program that keeps the file open, and shows how to identify and release such lingering file allocations using inode reference counts and lsof.

Liangxu Linux
Liangxu Linux
Liangxu Linux
Why Deleting a File with rm May Not Free Disk Space – Understanding Inode References

Background

On Linux, deleting a file with rm does not always free the occupied disk space because the file may still be open by a process.

Reproducing the Issue

Check free space on a mount point (example /boot) and create a 50 MiB random file:

$ df -h
/dev/sda11      454M  280M  147M  66% /boot
$ dd if=/dev/urandom of=/boot/test.txt bs=50M count=1
$ df -h
/dev/sda11      454M  312M  115M  74% /boot

Compile a small C program that opens the file and loops forever:

#include <stdio.h>
#include <unistd.h>
int main(void) {
    FILE *fp = fopen("/boot/test.txt", "rw+");
    if (!fp) { perror("open file failed"); return -1; }
    while (1) { sleep(1); }
    fclose(fp);
    return 0;
}
$ gcc -o openFile openFile.c
$ ./openFile

In another terminal delete the file:

$ rm /boot/test.txt

Disk usage remains unchanged because the process still holds an open file descriptor:

$ df -h
/dev/sda11      454M  312M  115M  74% /boot

After terminating the program, space is reclaimed:

$ df -h
/dev/sda11      454M  280M  147M  66% /boot

Why the File Is Not Fully Deleted

A file is removed from the directory namespace when its link count reaches zero, but the underlying inode and data blocks are kept as long as the inode reference count ( i_count) is non‑zero. Opening a file increments this count; rm only decrements the link count. The file appears “deleted” but continues to occupy space until all references are closed.

struct inode {
    unsigned long i_ino;   /* inode number */
    atomic_t    i_count;  /* reference count */
    unsigned int i_nlink; /* hard‑link count */
    /* ... */
};

Identifying Open‑Deleted Files

List files that are marked as deleted but still held open:

$ lsof | grep deleted

Example of a deleted file still open by the test program:

$ ls -al /proc/$(pidof openFile)/fd
lrwx------ 1 root root 64 ... 3 -> /boot/test.txt (deleted)

Closing the descriptor or terminating the process releases the space.

Practical Recommendations

Ensure long‑running services close file descriptors when they are no longer needed (e.g., after log rotation).

Use lsof or ls /proc/<pid>/fd to locate open‑deleted files when disk space does not recover.

Restarting the offending process is a simple way to free the space, but identifying the specific process avoids unnecessary restarts.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

file systeminodedisk spacelsof
Liangxu Linux
Written by

Liangxu Linux

Liangxu, a self‑taught IT professional now working as a Linux development engineer at a Fortune 500 multinational, shares extensive Linux knowledge—fundamentals, applications, tools, plus Git, databases, Raspberry Pi, etc. (Reply “Linux” to receive essential resources.)

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.