Ошибка коварна тем, что мы получаем сообщения об использовании дискового пространства на вроде таких failed: No space left on device. Мы не получаем сообщений, что закончились inode.
Смотрим дисковое пространство и видим, что с местом на диске всё в порядке.
При этом система отказывается работать с файлами, создавать новые, что по сути есть полный амбец. При изменении данных в таблицах баз, например — они начинают разрушаться.
В общем, даже после устранения ошибки, мы можем получить весьма неприятное состояние своих баз с неизвестными перспективами на восстановление таблиц. А уж если полезем туда раньше, чем дадим системе inod-ов то и подавно. Так что, первые две команды, которые нужно выполнить, если получаем ошибки связанные с фс:
df # смотрим объем df -i # смотрим количество заюзанных inode
Установили проблему:
Далее устанавливаем какие директории в системе используют наибольшее количество inode. Начинаем смотреть с корня, и далее подставляем в команду каждую подозрительную директорию:
for i in /*; do echo $i; find $i -xdev | wc -l; done for i in /home/username/*; do echo $i; find $i -xdev | wc -l; done
Обнаруживаем где зарыта собака и удаляем оттуда массу файлов:
rm -rf /home/username/tmp/*
В моём случае хочу «поблагодарить» разработчиков vestacp за отключённый по умолчанию сборщик мусора сессий в php.ini имевший, не понятно зачем, значение session.gc_probability = 0
Забавно, что для php.ini панельки сборщик включён, а в основном php.ini используемый сайтами он был выключен. В результате по исчерпанию inode после установки панели, несведущие пользователи vestacp при входе в панельку получают ошибку NO LANGUAGE DEFINED
Когда загуглил ошибку, оказалось, что для самых радикальных это становится причиной переустановки системы))) Прикольно, исчерпал inode на сессиях юзеров, будь добр, переустанови-ка всё нахер.