Why Deleted Files Still Occupy Disk Space? A Deep Dive into Linux VFS

Background

Sometimes the disk appears full with

df

, yet

du

shows plenty of free space.

Problem Reproduction

<code>-bash-4.2$ df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/vda1      ext4       30G    30G 0      100% /
devtmpfs       devtmpfs  489M     0  489M   0% /dev
tmpfs          tmpfs     497M     0  497M   0% /dev/shm
tmpfs          tmpfs     497M   50M  447M  11% /run
tmpfs          tmpfs     497M     0  497M   0% /sys/fs/cgroup
</code>

Running

du -h --max-depth=1 /home

reveals that only about 22 GB are used, leaving more than 10 GB unaccounted for.

<code>-bash-4.2$ du -h --max-depth=1 /home
16M /home
11G /home/logs
11G /home/serverdog
</code>

The missing space is caused by deleted files that are still held open by running processes. The

lsof

command lists such files, and restarting the offending processes releases the space.

<code>-bash-4.2# lsof | grep delete
mysqld 2470 mysql 4u REG 253,1 0 523577 /var/tmp/ibfTeQFn (deleted)
mysqld 2470 mysql 5u REG 253,1 0 523579 /var/tmp/ibaHcIdW (deleted)
mysqld 2470 mysql 6u REG 253,1 0 523581 /var/tmp/ibLjiALu (deleted)
mysqld 2470 mysql 7u REG 253,1 0 523585 /var/tmp/ibCFnzTB (deleted)
mysqld 2470 mysql 11u REG 253,1 0 523587 /var/tmp/ibCjuqva (deleted)
</code>

Virtual File System (VFS)

The VFS is the entry point for all file operations, providing an abstraction layer between user‑space libraries and specific file system implementations.

Common File Model

The VFS defines a common file model consisting of several object types:

Superblock object – metadata about the file system, stored in memory and on disk.

Inode object – stores file attributes; in memory it holds the

inode

structure, on disk it corresponds to the file control block.

File object – created when a file is opened; contains the

file

structure linking the process to the inode.

Dentry object – represents a directory entry; in memory it is a

dentry

structure, on disk it stores the name‑to‑inode mapping.

Directory Tree Construction

Linux builds the directory tree using both soft links and hard links. A hard link points directly to the same inode, while a soft link is a separate file containing the pathname of the target.

File & Process Management

When multiple processes open the same file, each gets its own file object, but they may share the same inode via hard links.

Inodes use a write‑back caching strategy: the inode is loaded into memory on open, stays there while in use, and is written back to disk when released. The reference count

i_count

is increased by

open()

and decreased by

close()

. When

i_count

reaches zero, the inode can be freed; if

i_nlink

is also zero, the disk blocks are released.

<code>* "in_use" - valid inode, i_count > 0, i_nlink > 0
* "dirty"  - as "in_use" but also dirty
* "unused" - valid inode, i_count = 0
</code>

The

rm

command ultimately performs an

unlink

, removing the directory entry and decrementing the inode's link count. The sequence involves opening the parent directory, locating the dentry, updating reference counts with

iget

and

iput

, and finally freeing memory and disk space when counts drop to zero.

Summary

Index vs Data

The core of file system behavior is the inode index, not the file data itself; separating index and data is key to understanding Linux file management.

Cache Strategy

Because Linux uses a write‑back cache, memory must be released before the corresponding disk space can be reclaimed.

Why lsof?

lsof

lists open files, allowing you to identify deleted files that are still held by processes, explaining why space is not immediately freed.