Не так давно был в командировке в городе Краснодар, где после очередного набега на книжный магазин купил себе второе издание «Восстановление данных. Практическое руководство.» (авторы Крис Касперски, Валентин Холмогоров, Ксения Кирилова). Должен отметить прекрасное качество книги, живой язык, описание интересных ситуаций и т.п.
Особенно меня заинтересовало устройство файловых систем ext3 и ext4, так как в одной из вакансий на hh.ru требовали знание их устройства.
А лично мне было ужасно интересно узнать, как всё это организовано. С давних пор имелся гештальт — считать файл с жёсткого диска по секторам, а после изменить его содержание так же не обращаясь к самому файлу напрямую.
После изучения книги гештальт был успешно закрыт, а я узнал новое для себя понятие inode. До этого что-то слышал, но благодаря книге, знания сложились в одну картину. Наконец я осознал причину того, почему жёсткие ссылки делаются в рамках одного раздела жёсткого диска! Но сейчас не об этом :).
В книге описывалась ситуация, в которой inode могут закончится быстрее, чем место на разделе жёсткого диска. На практике я такую ситуацию никогда не видел, помню удивился и… забыл.
Ну а сегодня ко мне обратились товарищи из соседней организации с проблемой — «не появляется графический режим, а в консольный заходит».
Сразу сказал посмотреть вывод команды
df -h
для оценки свободного места, но его было достаточно.
После этого попросил ввести команду создания файла в каталоге /tmp:
>/tmp/1
на что получил ответ «No space left on device».
Удивился. Знаю, что на компьютере полуживой жёсткий диск, смотрю результат вывода команды mount который попросил прислать, но раздел монтирован в режиме rw.
И тут меня осенило… Прошу набрать:
df -i
и вижу страшное… Inode исчерпаны. IUse% — 100 %.
Первый раз в моей практике стоит задача — найти много мелких файлов, а не мало больших.
Пишем простой скрипт:
for x in /var/*; do echo $x; find $x | wc -l; done
Его суть в том, что:
1) Цикл по очереди берёт папки и файлы в директории /var
2) Выводит название файла или директории
3) С помощью команды find выводит все файлы в директории и передаёт их команде wc которая считает их число и выводит значение.
Вывод выглядит так:
/var/foo.log
1
/var/spool
1000234
/var/log
1323
Таким образом мы видим, что разрослось нечто, в директории
/var/spool.
Повторно вводим команды с учётом выявленной директории:
for x in /var/spool/*; do echo $x; find $x | wc -l; done
И находим каталог exim4, где в input 700 000 файлов, а msglog 300 000.
Почему они там появляются совсем другая история, но если их очистить проблема будет решена.
Служба fly-dm создаст файл блокировки в /tmp/ и штатно запустится.
Вот так бывает.