Why Does Disk Space Appear Full Even When Files Are Deleted? Understanding Linux VFS

Background

Sometimes the disk usage shows as full, yet when inspecting individual directories there appears to be a large amount of free space.

Reproducing the problem

1. Run df to view filesystem usage; it reports 100% usage.

-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

2. Use du -h --max-depth=1 /home to sum directory sizes; the total is far less than the reported usage, leaving about 10 GB “missing”.

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

3. Why does this happen?

Root cause

Deleted files that are still opened by a process keep their blocks allocated, so the space is not released. The lsof command can list such “deleted” files. Restarting or terminating the offending processes frees the space.

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

Linux file‑system architecture

The Linux kernel separates file handling into a Virtual File System (VFS) layer that provides a uniform interface to various concrete file‑system implementations (ext3, NFS, etc.). VFS defines a common file model consisting of several objects:

Superblock object – metadata about the whole file system, stored both in memory (created at mount time) and on disk.

Inode object – represents a file’s metadata (size, permissions, timestamps). In memory it is an inode structure; on disk it corresponds to a file control block. Each inode has a unique number.

File object – created when a process opens a file; holds the state of the open file and links the process to the inode ( file structure).

Dentry object – represents a directory entry (name‑to‑inode mapping). In memory it is a dentry structure; on disk it is stored according to the specific file‑system layout.

Virtual File System diagram

Common file model operations

When a file is opened, VFS creates a file object and obtains the corresponding inode via iget. The inode’s reference count ( i_count) is incremented. Closing the file calls iput, which decrements the count; when it reaches zero the inode can be freed. The same mechanism applies to directory entries.

File and process interaction

Three processes can open the same file; each gets its own file object, while they may share the same inode (hard link) and dentry.

Inode write‑back policy

Linux uses a write‑back strategy: an inode is loaded into memory when the file is opened, kept there while in use, and written back to disk when modified. When no process references the inode ( i_count = 0) and its link count ( i_nlink = 0) is zero, the associated disk blocks are released.

File and disk management

The rm command ultimately performs an unlink system call, which removes a directory entry and decrements the inode’s link count. The deletion process can be described step‑by‑step:

The deleting process opens the parent directory, obtaining a directory file object. iget increments the parent directory’s inode reference count.

The directory data is read and converted into dentry objects.

Each dentry’s inode count is increased via iget.

The target directory entry is removed.

The inode’s link count i_nlink is decremented. iput decrements the inode’s usage count; if i_count reaches zero, the inode is freed from memory, and if i_nlink is also zero, the disk space is reclaimed. iput is called for the parent directory’s inode as well.

Summary

The apparent “missing” space is caused by files that have been deleted but are still held open by processes; the VFS architecture, inode reference counting, and write‑back policy explain why the space is not immediately reclaimed. Using df, du, and lsof to locate such files and terminating the responsible processes resolves the issue.

Key takeaways

Disk space is freed only after both the inode’s link count and usage count drop to zero.

Understanding VFS, inode, dentry, and file objects clarifies file‑system behavior.

Tools like df, du, and lsof are essential for diagnosing hidden disk usage.