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

-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

Running du -h --max-depth=1 /home reveals that only about 22 GB are used, leaving more than 10 GB unaccounted for.

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

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.

-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)

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.

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

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.