Корневая раздел не содержит инодов, несмотря на наличие свободного места на диске.

Вопрос или проблема

Я использую стек Bitnami WordPress на экземпляре AWS EC2. Хотя df -h показывает, что есть свободное место на диске, я не могу создать новые файлы или установить пакеты. После проверки с помощью df -ih выяснилось, что корневой раздел (/) использует 100% инодов:

bitnami@xxx:/opt/bitnami$ df -ih
Filesystem      Inodes IUsed IFree IUse% Mounted on
udev              486K   288  486K    1% /dev
tmpfs             488K   386  488K    1% /run
/dev/nvme0n1p1    1.9M  1.9M   762  100% /
tmpfs             488K     1  488K    1% /dev/shm
tmpfs             488K     2  488K    1% /run/lock
tmpfs             488K    17  488K    1% /sys/fs/cgroup
/dev/nvme0n1p15      0     0     0     - /boot/efi
tmpfs             488K     4  488K    1% /run/user/1000

Я нашел несколько команд в интернете (например, find / -xdev -type f | wc -l), чтобы понять, где может быть избыточное количество файлов, но они работают очень медленно или завершаются с ошибкой из-за нехватки доступных ресурсов.

Что можно сделать, чтобы эффективно найти и удалить (или архивировать) файлы, которые занимают все иноды, особенно на стеке Bitnami WordPress?
Есть ли известных местоположения (например, журналы, каталоги кэша и т. д.) в настройках Bitnami WordPress, где может накапливаться большое количество мелких файлов?
Если очистка файлов недостаточна, является ли изменение размера или форматирование раздела с большим количеством инодов единственным долгосрочным решением?

Спасибо 🙂

———————————————
ОБНОВЛЕНИЕ (после предложения @asktyagi):

Я увеличил диск на 20 ГБ, и, похоже, это сработало, судя по выводу df -hi:

Filesystem        Inodes IUsed IFree IUse% Mounted on
udev                486K   288  486K    1% /dev
tmpfs               488K   384  488K    1% /run
/dev/nvme0n1p1      3.2M  1.9M  1.3M   60% /
tmpfs               488K     1  488K    1% /dev/shm
tmpfs               488K     2  488K    1% /run/lock
tmpfs               488K    17  488K    1% /sys/fs/cgroup
/dev/nvme0n1p15        0     0     0    - /boot/efi
tmpfs               488K     4  488K    1% /run/user/1000

и df -h:

Filesystem       Size  Used Avail Use% Mounted on
udev             1.9G     0  1.9G   0% /dev
tmpfs            391M  5.3M  385M   2% /run
/dev/nvme0n1p1    49G   17G   31G  36% /
tmpfs            2.0G     0  2.0G   0% /dev/shm
tmpfs            5.0M     0  5.0M   0% /run/lock
tmpfs            2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/nvme0n1p15  124M  278K  124M   1% /boot/efi
tmpfs            391M     0  391M   0% /run/user/1000

Ответ или решение

Теория

Одним из наиболее распространенных вопросов, с которыми могут столкнуться системные администраторы и инженеры в области информационных технологий, является проблема нехватки инодов на файловой системе, даже при наличии свободного дискового пространства. Иноды представляют собой структуры данных, содержащие метаинформацию о файлах, но не сам контент файлов. На файловых системах Linux, таких как ext4, каждый файл или директория требует собственного инода.

Когда количество доступных инодов заканчивается, система не может создать новые файлы, даже если на диске остается много свободного физического пространства. Обычно такое происходит, когда система содержит большое количество маленьких файлов, например, временные файлы, лог-файлы или кэши. Именно эта ситуация и описана в вашем вопросе, что проявляется как невозможность создания новых файлов и установки пакетов.

Пример

Вы работаете с Bitnami WordPress на AWS EC2. Ваша файловая система показывает полное использование инодов, в то время как отчет df -h указывает на наличие свободного дискового пространства. На сервере:

bitnami@xxx:/opt/bitnami$ df -ih
Filesystem      Inodes IUsed IFree IUse% Mounted on
/dev/nvme0n1p1    1.9M  1.9M   762  100% /

Это свидетельствует о том, что root-раздел полностью исчерпал свои иноды.

Применение

Для решения данной проблемы вы можете предпринять следующие шаги:

Идентификация и удаление ненужных файлов:
- Очищение кэша и временных файлов: Начните с поиска директории, в которых сохраняются кэш и темп-файлы WordPress и его плагинов. Это может включать директории /tmp, /var/cache, и временные директории внутри /opt/bitnami/apps/wordpress/.
- Логи и журналы: Проверьте место, где могут накапливаться логи веб-сервера, например /opt/bitnami/apache2/logs/ или /opt/bitnami/apps/wordpress/htdocs/wp-content/debug.log.
Команда find может помочь в поиске и удалении небольших файлов:
```
find / -xdev -type f -size -1M -exec ls -lh {} \; | awk '{ print $NF ": " $5 }'
```
Это выведет список всех файлов меньше 1 МБ.
Архивирование и вывод файлов:
- Архивирование устаревших данных: Используйте утилиту tar для архивации старых логов или временных файлов, если их нельзя сразу удалить.
```
tar -czvf old_logs.tar.gz /path/to/logs
```
Это может высвободить иноды, уменьшив количество файлов.
Мониторинг и автоматизация:
- Установка ротации логов: Конфигурируйте лог-менеджеры, такие как logrotate, чтобы автоматизировать архивирование и удаление старых логов.
- Мониторинг файловой системы: Регулярный мониторинг использования инодов и установка уведомлений, чтобы не повторять ошибку в будущем.
Ресайзинг файловой системы:
- Увеличение количества инодов: Если упомянутые действия не позволили освободить достаточное количество инодов, может потребоваться увеличение их числа с помощью изменение файловой системы, например, расширением файловой системы и перенастройкой её параметров.
Текущая ситуация была решена увеличением дискового пространства, что видимо также увеличило количество инодов:
```
/dev/nvme0n1p1      3.2M  1.9M  1.3M   60% /
```

Итак, ключевым моментом является не только непосредственное решение проблемы, но и своевременная профилактика её повторного появления путем настройки правильной стратегии управления малочисленными файлами и постоянного мониторинга состояния файловой системы.