Your Files Never Really Die in Linux—Until They Do

You delete a file. But nothing happens.

You run:

rm large_file.log

You expect disk space to increase. But sometimes… it doesn’t. No error. No warning. Just… no space freed.

So what’s going on?

The hidden reason: the file isn’t really gone

This usually happens because:

• A process is still holding the file open

• The file has no name anymore… but still exists

In Linux, a file can exist without a filename.

That sounds wrong—but it’s not.

Quick mental model

A file is not just “a file”. It contains the following 3 components:

• filename → what you see in the directory

• inode → metadata (size, permissions, pointers to data)

• data blocks → actual contents

When you run rm, you’re not deleting all of this at once.

You’re starting a lifecycle. Linux doesn't delete files by removing references, that’s only step one. In reality, deletion spans three distinct layers!

The Three Layers of Deletion

Understanding this is the difference between guessing and actually knowing what’s happening.

1. VFS Layer (Virtual File System)

This is where system calls like unlink() operate.

What happens here:

• The directory entry (dentry) is removed from the memory (Fun fact, they only exist in memory and are never written onto the disk!)

• The filename → inode mapping is gone (Notice, only the mapping is gone, not the file)

Before:
file.txt → inode 123

After unlink():
(no name)   inode 123 still exists

2. Filesystem Layer (ext4, XFS, etc.)

Now the filesystem decides what to do.

If:

• link count = 0

• no process is using the file

Then:

• inode is marked free (Free does NOT mean that it has been deleted)

• data blocks are marked free

inode 123 → marked reusable
blocks → marked reusable

3. Storage Layer (HDD vs SSD)

This is where true deletion happens—or doesn’t.

HDD:

• Data stays until overwritten

• Recovery often possible

SSD (with TRIM):

• OS tells disk: “these blocks are unused”

• Disk may erase them proactively

After this step, recovery may never be possible!

---

Let’s walk the full lifecycle

Here’s what actually happens after rm:

t0: file exists
t1: unlink() → filename removed
t2: link count = 0
t3: inode marked free
t4: blocks marked free
t5: blocks reused
t6: data overwritten (true deletion)

Visualizing the decay

[ Named File ]
     ↓ unlink()
[ Unnamed inode ]
     ↓ no references
[ Marked free ]
     ↓ reuse
[ Partially overwritten ]
     ↓ overwrite
[ Gone forever ]

At each step, the file is less recoverable.

But never immediately gone.

The “open file” trap (why disk space isn’t free)

Let’s go back to the original mystery.

rm large_file.log

The file is "officially" deleted but disk space doesn’t increase.. Why?

Because:

Process → file descriptor → inode → data blocks

Even after unlink:

(no filename)
Process → still holding inode

The file is invisible, but still consuming space. Once the file is closed by the process, the space is actually marked as reusable. Hence, "Deleted data is always recoverable" is a MYTH!

Recovery is opportunistic, fragile and time-sensitive.

Unfortunately, recovery works better at systems doing a bad job managing it's own storage.

Final takeaway

Deletion in Linux is not a single action.

It’s a gradual decay:

• First, the name disappears

• Then the structure is freed

• Finally, the data is overwritten

And only at the end…

the file is truly gone.

Thanks for reading!