Free Gigabytes Are Available, But the File Won't Create: Check Inodes
We analyze the situation where Linux reports no space despite free disk capacity: how to check inodes and find directories with a high number of files.

In this article
Ошибка отсутствия места не всегда означает, что закончились гигабайты. Для хранения файлов файловая система использует служебные записи — inode. Когда доступные записи исчерпаны, множество маленьких файлов может остановить запись раньше, чем заполнится объём диска.
Проверьте тот путь, где возникает ошибка
Инструкция подходит для Linux с GNU Coreutils. В примерах используется /var. Подставьте каталог, в котором приложение не может создать файл: проверка домашней директории не заменяет проверку отдельного тома с почтой или кэшем.
df -h /var
df -i /var
Первая команда показывает блоки данных, вторая — inode. Смотрите на доступное количество и долю использования. Некоторые файловые системы управляют inode иначе и не показывают привычный фиксированный предел. Поэтому прочерк или необычные значения нужно разбирать с учётом типа тома, а не считать доказательством исправности.
Ищите количество, а не только размер
Большой видеофайл и миллион маленьких файлов создают разную нагрузку на служебные структуры. Для поиска ветви с большим числом записей GNU du умеет считать inode:
du --inodes -x -d1 /var
Проверка ограничена одной файловой системой и выводит первый уровень каталогов. Затем можно повторить её внутри подозрительной ветви. Обход каталога с огромным числом файлов способен занять время и нагрузить хранилище; не запускайте его циклически каждую секунду.
Если вывод содержит отказ в доступе, часть дерева не посчитана. Обсудите необходимый доступ с администратором. Отсутствие каталога в итоговом списке при ошибках чтения не означает, что в нём ничего нет.
Типичный сценарий
Предположим, приложение каждый раз создаёт новый файл сессии и никогда не удаляет истёкшие. Общий размер остаётся умеренным, но количество объектов непрерывно растёт. Удаление нескольких крупных архивов освободит блоки, однако почти не изменит ситуацию с inode.
Другой пример — почтовая очередь. Здесь массовое удаление файлов может уничтожить письма, которые ещё должны быть доставлены. Сначала нужно определить назначение каталога и штатный механизм обработки просроченных объектов. Название «временный» не делает данные автоматически ненужными.
Как проверить исправление
Результат диагностики запишите как связку: путь, файловая система, свободные inode, каталог с наибольшим числом записей и приложение-владелец. После согласованной очистки повторите df -i и проверьте штатное действие приложения, ранее завершающееся ошибкой.
Затем сравните показатели через рабочий интервал. Если свободные записи снова быстро исчезают, необходимо исправлять срок хранения или обработку очереди. Увеличение диска не является универсальным решением: возможность увеличить число inode зависит от файловой системы и способа её расширения.
Не меняйте лимиты и не запускайте рекурсивное удаление по одному графику. Для устойчивого результата нужен понятный ответ: какие файлы создаются, сколько они должны храниться и кто контролирует завершение очистки. В мониторинге полезно наблюдать отдельно за свободными блоками и свободными inode — эти два показателя отвечают на разные вопросы.
A lack of space error does not always mean gigabytes are exhausted. File systems use service records called inodes to store files. When available records are exhausted, a multitude of small files can stop writing before the disk volume is filled.
Check the path where the error occurs
This guide applies to Linux with GNU Coreutils. The examples use /var. Substitute the directory where the application cannot create a file: checking the home directory does not replace checking a separate volume with mail or cache.
df -h /var
df -i /var
The first command shows data blocks, the second shows inodes. Look at the available amount and usage percentage. Some file systems manage inodes differently and do not display the familiar fixed limit. Therefore, dashes or unusual values must be analyzed considering the volume type, not treated as proof of correctness.
Look for the count, not just the size
A large video file and a million small files place different loads on metadata structures. To find the branch with a large number of records, GNU du can count inodes:
du --inodes -x -d1 /var
The check is limited to one file system and outputs the first level of directories. You can then repeat it inside the suspicious branch. Traversing a directory with a huge number of files can take time and load the storage; do not run it cyclically every second.
If the output contains an access denial, part of the tree was not counted. Discuss the required access with the administrator. The absence of a catalog in the final list due to read errors does not mean it is empty.
Typical scenario
Suppose the application creates a new session file every time and never deletes expired ones. The total size remains moderate, but the number of objects continuously grows. Deleting several large archives will free up blocks, but it will hardly change the inode situation.
Another example is a mail queue. Here, mass deletion of files can destroy messages that still need to be delivered. First, you must determine the purpose of the directory and the standard mechanism for processing expired objects. The name "temporary" does not automatically make data unnecessary.
How to verify the fix
Record the diagnostic result as a set: path, file system, free inodes, the directory with the highest number of records, and the owning application. After agreed cleanup, repeat df -i and verify the normal operation of the application that previously ended with an error.
Then compare the metrics over a working interval. If free records disappear again quickly, you need to adjust the retention period or queue processing. Increasing disk space is not a universal solution: the ability to increase the number of inodes depends on the file system and the method of its expansion.
Do not change limits or schedule recursive deletion. A stable result requires a clear answer: which files are created, how long they must be retained, and who controls the completion of cleanup. In monitoring, it is useful to track free blocks and free inodes separately, as these two metrics answer different questions.

Discussion 0
Share your experience and ask questions. Comments without links appear after editorial review.
No comments yet. Start the discussion.