ext4 runs out of inodes before blocks · Linux Fix Lab

Symptoms & scope

Creating a new file fails but extending an existing file may work.
df reports free blocks but df -i reports nearly no free inodes.

Relevant environment

ext4 filesystems with a finite inode table and workloads producing many small files.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

Caches, mail queues or generated-file trees may consume the filesystem inode population.
Quota limits or metadata damage can resemble exhaustion; confirm both filesystem identity and counters.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace /affected/path with an existing path on the affected filesystem. Read inode availability without changing files.

df -i /affected/path

Interpret the result: IUse% near 100% with few IFree supports inode exhaustion. This alone does not show which directory generated the files.

Check 2

Replace the path with the suspected cache or queue. GNU du counts entries within this filesystem; unreadable directories may require read privileges.

du --inodes -x --max-depth=1 /suspected/directory

Interpret the result: The largest inode counts localize file populations. Permission errors or hidden mounts make the total incomplete; shared hard links are not counted like distinct new inodes.

Evidence-guided next steps

Use the owning application to prune files

If a cache or queue accounts for the inode population, pause its producer and use that application’s retention or cleanup controls to remove confirmed disposable items. Recheck IFree before restarting production.

Precautions: Do not recursively delete system directories or active queue items. Move-to-trash on the same filesystem may retain the inode population.

Recovery / rollback: Restore required files from backup and return the application’s previous retention settings if needed.

Did this solution help you?

Share this solution #

Move the workload to suitable storage

If the workload genuinely requires more files than this ext4 layout provides, migrate it with a verified copy to a filesystem provisioned for that file count. Use an application path setting or a deliberate dedicated mount.

Precautions: Changing inode density normally requires recreating ext4 and is destructive; do not format the current filesystem as a quick fix.

Recovery / rollback: Keep the original workload copy and path configuration until the migration is verified, then restore the path if the replacement is unsuitable.