Disk space vs inode exhaustion

What it means

An inode holds metadata about a file, distinct from its payload—the file's contents. This simulation represents new-file creation as a request against two budgets: one inode per new file, plus the selected payload bytes for each file. File count determines one requirement; file count multiplied by payload size determines the other.

The useful diagnostic question is not just “How much space is free?” It is “Which resource is unavailable on the filesystem containing the failed destination?”

Try it

Simulation: change Free inodes from 2 to 3, then inspect the computed result and explanation. Use Compare with baseline to display the baseline and current outcomes together. This is a local example, not a filesystem check; no real files are created or changed.

The baseline result is Insufficient inodes. 3 files need 3072 payload bytes and 3 inodes; available: 4096 bytes and 2 inodes. More capacity of the other resource does not resolve this shortage. Changing only the inode budget lets you test that cause without changing the payload requirement. A modeled fit is not permission to write: real allocation and access restrictions remain untested.

Keep Free payload bytes = 4096, New files requested = 3 and Payload bytes per file = 1024. Change only Free inodes.

Reset restores Free payload bytes = 4096, Free inodes = 2, New files requested = 3 and Payload bytes per file = 1024. It clears input errors and the comparison with baseline. It does not change your independently opened or closed FAQ answers or About this model panel.

How it works

The model makes two comparisons:

Payload bytes required = New files requested × Payload bytes per file
Inodes required = New files requested

A request fits only when neither requirement exceeds its corresponding available budget. Inodes represent file metadata separately from the file's payload; the simulation charges one inode for each new file.

In the baseline, the payload comparison passes, but the inode comparison fails. That intermediate state explains the outcome: enough payload capacity remains, yet the modeled request still lacks the metadata capacity for one of its files. Increasing Free payload bytes alone leaves the inode comparison unchanged.

The reverse is also possible: a payload requirement can exceed Free payload bytes while the inode requirement fits. Both comparisons can fail together. For example, 2 new files of 1 payload byte each need 2 payload bytes and 2 inodes; with both available budgets set to 0, the result is Insufficient payload bytes and inodes. The model reports both shortages rather than treating one as an explanation for the other.

Worked example

This is a synthetic baseline, not a captured production observation.

The result is Insufficient inodes. 3 files need 3072 payload bytes and 3 inodes; available: 4096 bytes and 2 inodes.

The payload requirement is 3 × 1024 = 3072 bytes, which is 1024 bytes below the available payload budget. The inode requirement is 3, which exceeds the available inode budget by 1. That is why the request fails this model despite its spare payload bytes. More capacity of the other resource does not resolve this shortage.

What changes when the condition changes

Change Free inodes from 2 to 3. Keep Free payload bytes = 4096, New files requested = 3 and Payload bytes per file = 1024.

The result becomes Both modeled budgets fit. 3 files need 3072 payload bytes and 3 inodes; available: 4096 bytes and 3 inodes.

The payload requirement has not changed. The difference is that the third requested file now has an inode available, so the inode requirement exactly meets its budget. The model still leaves 1024 payload bytes, but no spare inodes. This is not permission to write: real allocation and access restrictions remain untested.

In practice

For a failed new-file creation on Linux, begin with read-only evidence. Use an account authorized to inspect the affected destination, and record the exact error, the target path and when the failure occurred. This page does not require administrator privileges or authorize a change.

With GNU df available, replace the example path below with the existing destination directory. Inspect that same directory in both reports—not an unrelated filesystem that happens to have free space.

df /path/to/destination-directory
df -i /path/to/destination-directory

The first command reports block-space usage; the second selects inode usage. Verify that both reports identify the filesystem containing the affected directory before interpreting the available capacity.

STOP before deleting files, changing access settings or expanding storage if the filesystem or cause is uncertain. These reports do not identify disposable data or establish a safe repair. Cleanup would require explicit authority, retention rules and an identified scope; any actual change needs its own verification and recovery plan. No mutation or write test is part of this read-only check.

Limits and unknowns

Each new file uses one inode and exactly the selected payload bytes in this simulation. Real allocation units, directories, metadata overhead, quotas and reserved blocks are excluded. The available-byte input is therefore a teaching budget, not a promise that a real filesystem will allocate the same amount.

For valid inputs, the model answers only whether these two declared budgets fit. It does not inspect a filesystem, diagnose an application error, or test whether an account can write. A real failure remains unexplained when the relevant reports or other necessary evidence are missing—even if the synthetic result says both budgets fit.

An invalid entry replaces the calculated outcome with an input error. Correct the entry or use Reset; a previous valid result must not be applied to the invalid draft.

Without JavaScript, the initial example and its explanation remain readable, but the interactive controls are unavailable. No real files, commands or external checks are run by the scene.

What to carry forward

Use the report for the constrained resource to guide your next investigation. Free bytes do not rule out inode exhaustion, and spare inodes do not establish sufficient block space. If neither report explains the failure on the affected filesystem, preserve the error and leave the cause unresolved rather than treating cleanup as a diagnosis.