Linux Interview Question 4: No Space Inode Exhaustion
Linux Interview Questions · Test 1 · question 4 of 10
An application writing session files to /var/spool/app starts failing with No space left on device. /var is an ext4 filesystem on a local disk, and df -h /var reports it as only 38% used. You find that the nightly cleanup job has been broken for months, and the spool directory now holds millions of tiny files.
Which command best confirms the most likely cause?
Show answer and explanation
Answer:
Every file needs an inode, the structure that stores its metadata (owner, mode, timestamps, pointers to its data blocks). On ext4 the number of inodes is fixed when the filesystem is created. Millions of tiny files can use up every inode long before the data blocks fill, and creating a file then fails with ENOSPC, the same "No space left on device" error you see when the disk is full. df -h reports only block usage, which is why it looks healthy. df -i lists inode usage instead of block usage, and an IUse% of 100% confirms the diagnosis. The fix is to delete the stale files and repair the cleanup job.
Option A is wrong because du measures bytes. It would point at the spool directory, but it cannot show that inodes, not bytes, are the exhausted resource, and df already says bytes are plentiful.
Option B is wrong because RAM and swap have nothing to do with free space on an on-disk ext4 filesystem.
Option D is wrong because it tests the *other* classic "disk full" puzzle: space held by deleted files that are still open. Those files still use data blocks, so df -h would show the filesystem as full while du shows less. Here df -h shows 38%, so blocks are not the problem.
References: df(1) - Linux manual page; inode(7) - Linux manual page