Inodes, dentries, and the VFS — how Linux tracks files

The filesystem path is for humans. The kernel does not look up files by path — it looks them up by inode number, an integer that uniquely identifies a file on a particular filesystem.

What an inode stores

Each file on disk has an inode. The inode holds everything the kernel needs to access the file except its name and its contents:

The path is not in the inode. The kernel maintains a separate structure (the dentry cache) that maps paths to inodes in memory.

Inspecting inodes

$ ls -li /etc/passwd /etc/shadow /etc/group

12345 -rw-r--r-- 1 root root 3010 Aug  9 11:11 /etc/passwd
12346 -rw-r----- 1 root shadow 1840 Aug  9 11:11 /etc/shadow
12347 -rw-r--r-- 1 root root  1024 Aug  9 11:11 /etc/group

The inode number is unique within a filesystem. The same inode number can appear on different filesystems and refer to different files.

Inode exhaustion

Every filesystem is created with a fixed number of inodes. A small file uses one inode; a large file uses one inode. The filesystem has a fixed pool regardless of file size.

This matters in production:

$ df -i /var

Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sdc1      6553600 6549870   3730  100% /var

Why df and du disagree

The classic production question: df says the filesystem is full, but du on every directory adds up to half the size. What is missing?

The gap is almost always deleted-but-open files. A process holds a file descriptor open after the file has been unlinked; the file’s inode is preserved (because the link count never hit zero) and its blocks are not freed; but the file no longer appears in any directory, so du does not see it.

$ lsof +L1 | head

COMMAND   PID  USER   FD   TYPE DEVICE    SIZE/OFF NLINK  NODE NAME
mysqld   1234 mysql   42u   REG  253,1 5242880000     0  67890 /var/lib/mysql/ibdata1 (deleted)
logrotat  5678 root    4w   REG  253,1  104857600     0  34567 /var/log/nginx/access.log (deleted)

The remediation: restart or signal the holding process (often after rotating logs without copytruncate), or use fuser / lsof to identify the process holding the file and decide whether the file-descriptor leak is real.

Knowledge check