Что такое Inode
Inode — это структура данных в которой хранится информация о файле или директории в файловой системе. В файловой системе Linux, например Ext4, у файла есть не только само его содержимое, например, тот текст, но и метаданные, такие как имя, дата создания, доступа, модификации и права. Вот эти метаданные и хранятся в Inode. У каждого файла есть своя уникальная Inode и именно здесь указано в каких блоках находятся данные файла.
Это довольно низкоуровневое понятие, но обычным пользователям приходится взаимодействовать с ним когда эти самые Inode заканчиваются. Возможно вы уже встречались с ошибкой когда место на диске ещё есть, но программа не может создать файл, потому что Inode закончились. В этой статье мы подробно разберемся что такое Inode, а также попытаемся выяснить как избежать связанных с ними проблем.
Что такое Inode в Linux?
Как я уже сказал выше, Inode или I-node или индексный дескриптор — это структура данных, в которой хранятся метаданные файла и перечислены блоки с данными файла. Но начать надо с файловой системы. Файловые системы Ext используют блоки для хранения данных. По умолчанию размер одного блока равен 4092 байта. В начале раздела расположен суперблок, в котором находятся метаданные всей файловой системы, а ним идут несколько зарезервированных блоков, а затем размещена таблица Inode и только после неё блоки с данными. Таким образом, все Inode размещены в начале раздела диска.
Директории — это тоже Inode типа директория, в которых вместо содержимого файла содержится список имён файлов и номера их Inode. Корневая папка в Ext4 имеет номер Inode — 2. Вы можете посмотреть информацию о ней с помощью утилиты debugfs. Утилите в параметрах надо передать диск, на котором расположена файловая система:
sudo debugfs /dev/nvme0n1p5
Затем выполните такую команду:
Здесь указано, что эта Inode имеет тип Directory, права 755. Её владелец и группа root, потому что идентификатор пользователя 0. Чуть ниже расположена информация про время создания, модификации и доступа. А в самом низу находятся блоки с данными этой Inode. Именно там хранится список файлов и папок директории. Вы можете посмотреть содержимое блока командой dump_block:
debugfs: block_dump 9238
Утилита выведет данные в HEX и ASCII формате, и в них будет видно имена папок. Но увидеть номера Inode здесь не получится без дополнительных программ. Проще всего их можно посмотреть с помощью команды ls:
Здесь в первом же столбике находится номер Inode для файла или папки. Для примера можно посмотреть ещё информацию про testfile с номером Inode 1128:
В разделе EXTENTS есть номер блока, в котором находятся данные файла. В данном случае это 6596316. В нём можно посмотреть содержимое файла:
debugfs: block_dump 6596316
Вот так это всё работает на уровне файловой системы. Посмотреть Inode идентификаторы файлов можно также с помощью команды ls. Для этого надо передать ей опцию -i:
Здесь они будут тоже в первой колонке. Обратите внимание, что у каждого файла, папки или символической ссылки уникальный номер Inode. Исключение составляют только жесткие ссылки. Количество Inode в файловой системе ограничено, оно определяется при инициализации файловой системы. Посмотреть текущее количество Inode можно командой tune2fs:
sudo tune2fs -l /dev/nvme0n1p5
Нужная информация находится в поле Inode count. Посмотреть Inode можно с помощью утилиты df передав ей опцию -i:
Как видите, на моём корневом разделе использовано 29% Inode, а блоков у меня уже использовано 95%. Но если бы у меня было очень много мелких файлов, то место бы ещё осталось, а доступные Inode закончились. Тогда бы возникла ошибка создания файла, даже несмотря на то, что место ещё есть. Чтобы избежать такой ситуации надо тщательно планировать как вы будете использовать файловую систему.
Вы не можете изменить количество Inode для существующей файловой системы, зато можете указать для новой с помощью опции -N. Например:
mkfs -t ext4 -N 3000000 /dev/nvme0n1p5
В данном случае будет создана файловая система с тремя миллионами индексов Inode. Ещё можно не указывать точное количество Inode, а указать количество байт в одной Inode, это может быть удобно, если вы знаете средний размер ваших файлов, которые будут хранится в файловой системе. Например:
mkfs -t ext4 -i 2K /dev/nvme0n1p5
В качестве альтернативы, можно использовать файловую систему Btrfs, в которой Inode не могут закончиться потому что они генерируются динамически по мере необходимости.
Выводы
В этой статье мы рассмотрели что такое Inode в Linux, а также что произойдёт если доступное количество Inodes закончатся. Будьте осторожны при создании файловой системы и думайте какие файлы в ней будут размещены и сколько их там будет чтобы избежать проблем с Inode.
Источник
Переполнение inodes
Inodes, или индексные дескрипторы («описатели») — это структуры данных в системах Unix, используемые для хранения информации о файлах и каталогах. Так как дескрипторы являются, по сути, данными о данных, их также называют метаданными.
Inodes хранят такие свойства файла, как его размер, информацию о владельце, группу, к которой принадлежит файл, права доступа, счетчик жестких ссылок, место, где на данный момент располагается содержимое файла, временные отметки (время последней модификации файла, последнее время доступа к файлу и т.д.) и пр. Другими словами, дескриптор содержит в себе всю информацию о файле, кроме его имени и содержимого.
Чем больше создано файлов, тем больше индексных дескрипторов занято. Чрезмерное количество файлов (например, файлы кэша или почтовая очередь) может привести к отсутствию свободных inodes и, как следствие, к ошибкам в работе сервера и сообщениям о недостаточном дисковом пространстве, несмотря на его фактическое наличие. Решать проблему потребуется удалением ненужных файлов или директорий.
Получить информацию о количестве использованных и занятых дескрипторов можно при подключении по SSH, с помощью следующей команды:
Значения в выводе команды:
- Inodes — объем доступного пространства для индексных дескрипторов;
- IUsed — объем, занятый дескрипторами;
- IFree — свободный объем;
- IUse% — объем, занятый дескрипторами, в процентах.
Для решения проблемы с недостатком свободных inodes необходимо удалить достаточное число файлов или каталоги с большим числом файлов.
Найти директории, содержащие в себе большое количество файлов, можно с помощью команды ниже:
Удалить ненужные файлы и директории можно с помощью команды rm. Будьте внимательны при ее использовании.
Источник
Закончились иноды в /var
Как узнать в каком каталоге скопилось наибольшее количество использованных инодов и какую ФС лучше всего взять на замену для /var?
P.S. /var/log вынесено отдельно.
какую ФС лучше всего взять на замену для /var
Осталось найти нормальные драйвера под неё.
ЕМНИП рейзер создает иноды по мере необходимости. 
i-rinat , поправь, если я не прав.
Каким г^Wобразом ты забил /var ?
Иноды используются для файлов. Число использованных inode должно совпадать с числом всех файлов ( включая директории, ссылки, файлы устройств, каналы и т.п. )
Идея понятна? Второй вызов find вместе с каналом сделай в виде отдельного скрипта, мне сейчас некогда
Сделал tree /var>>var.txt и беглым просмотром обнаружил каталог /var/spool/exim4/input, засранный 42384 файлами с именами типа 1Rvs5t-00052Q-Uv-H, в которых каждые полчаса крон бодро рапортовал об очистке каталогов с сессиями PHP (кстати, как это оповещение отключить?). Судя по всему иноды закончились ещё где-то 7 марта, т.к. более новых файлов нет. Сделал tar cpjf input.tar.bz2 /var/spool/exim4/input для дальнейшего изучения и rm -f /var/spool/exim4/input/*. Стало лучше:
Или используй XFS.
Оно же вроде для мелких файлов не очень?
Да нормально. Хотя по сравнению с ext4 не очень. Ну тогда читай указанный ман, там написано как определить число inode при создании ФС.
рейзер создает иноды по мере необходимости
там нет инодов. Место под то, что в ext4 хранится в инодах, выделяется динамически. Но там свои странности. Лучше пересоздать ext4 с большим числом инодов.
обнаружил каталог /var/spool/exim4/input, засранный 42384 файлами
Вопрос почему у тебя почта не уходит и письма валяются в очереди exim’a?
отменять отправку писем cron’ом, в данном случае — костыль.
ext4 же, в тегах есть.
Вопрос почему у тебя почта не уходит и письма валяются в очереди exim’a?
Я не настраивал exim из-за отсутствия необходимости работы с почтой, кроме того его демон пришлось отключить т.к. он почему-то тормозил загрузку системы.
отменять отправку писем cron’ом, в данном случае — костыль.
Просто не вижу смысла каждые полчаса рапортовать об очистке каталога.
Сделал tree /var>>var.txt и беглым просмотром обнаружил каталог /var/spool/exim4/input, засранный 42384 файлами
я не понял, а что var такой маленький, и почему ты, одмин, почту не читаешь? Сделай var побольше, а если не хочешь читать почту — отключи (как — не помню, искать лень. Как в твоём php-скрипте — даже не знаю).
Но о смене ФС для /var всё равно задумываюсь.
ктож под /var так мало инодов выделяет-то. У меня вот десктоп без всяких серверов:
ЗЫЖ ИМХО ext4 — самая лучшая для хранения БОЛЬШОГО числа мелких файлов, особенно в одном каталоге. Всё остальное — глючное и тормозное говно.
А зачем больше? Если не считать срача с почтой, скопившегося за пару лет, его вполне хватает:
и почему ты, одмин, почту не читаешь?
Не вижу смысла читать об очистке каталога каждые полчаса (кто же её столько будет читать-то?). Если с этим внезапно возникнут какие-то проблемы — я это увижу и без почты.
а если не хочешь читать почту — отключи
ктож под /var так мало инодов выделяет-то.
Я просто оставил дефолт, не думая что с этим возникнут какие-то грабли.
А зачем больше? Если не считать срача с почтой, скопившегося за пару лет, его вполне хватает:
мог бы и пару лет назад спросить у меня, я-бы тебе ещё тогда сказал, что мало. Либо почту пилить/читать/следить надо, либо больше инодов делать.
Не вижу смысла читать об очистке каталога каждые полчаса (кто же её столько будет читать-то?).
аффтор php-скрипта наверное. Я откуда знаю, кто шлёт?
мой ответ см. там же
Я просто оставил дефолт, не думая что с этим возникнут какие-то грабли.
ну… на ошибках учатся.
мог бы и пару лет назад спросить у меня, я-бы тебе ещё тогда сказал, что мало. Либо почту пилить/читать/следить надо, либо больше инодов делать.
Вообще их хватает. Причина возникшего срача — костыльная изкоробочная конфигурация для автоочистки файлов PHP-сессий в дебиане.
аффтор php-скрипта наверное. Я откуда знаю, кто шлёт?
PHP-скрипты там вообще не при чём. Ты же отвечал на моё сообщение, в котором это было написано:
крон бодро рапортовал об очистке каталогов с сессиями PHP
для var не хватает. Почта бывает и от других ошибок.
Ты же отвечал на моё сообщение, в котором это было написано: «крон бодро рапортовал об очистке каталогов с сессиями PHP»
crond рапортовал об ОШИБКЕ, потому-что юниксвейно выполнять команду молча, и не жужжать. А если жужжит → ошибка, и её нужно исправить. Надо было раньше почту читать, два года назад, когда сервер подымал.
для var не хватает. Почта бывает и от других ошибок.
Вряд-ли от чего-то другого она будет сыпаться каждые полчаса.
Начинать комментарии с решётки — это уже ошибка. Прямо какое-то соревнование велосипедов „кривой и ещё кривее”.
Вряд-ли от чего-то другого она будет сыпаться каждые полчаса.
было. Я точно даже и не помню, от чего. Тоже накриворучил где-то.
Начинать комментарии с решётки — это уже ошибка. Прямо какое-то соревнование велосипедов „кривой и ещё кривее”.
это PHP, смирись. Или юзай нормальные ЯП.
костыльная изкоробочная конфигурация для автоочистки файлов PHP-сессий в дебиане.
Вот не надо наговаривать. У меня не сыпется же, однако исправно выполняется очистка. Значит ты что-то сам наисправлял.
это PHP, смирись. Или юзай нормальные ЯП.
PHP тут не при чём. Проблема в конфигах, в каждом из которых свой собственный велосипедный формат.
PHP тут не при чём. Проблема в конфигах, в каждом из которых свой собственный велосипедный формат.
научись читать, цитирую твой пост:
PHP Deprecated: Comments starting with ‘#’ are deprecated in /etc/php5/apache2/php.ini
У меня не сыпется же, однако исправно выполняется очистка
Для того, чтобы у меня исправно выполнялась очистка для виртуальных хостов мне пришлось ещё вручную его править, прописывая путь к tmp-каталогам, хотя эти каталоги уже заданы в настройках виртуального хоста. ИМХО это костыль.
Да, уже разобрался. Использовал # вместо ; для комментариев в /etc/php5/apache2/php.ini.
PHP Deprecated: Comments starting with ‘#’ are deprecated in /etc/php5/apache2/php.ini
И при чём здесь PHP как ЯП? Совсем слака мозг выела.
«не очень» было пару лет назад. сейчас «очень».
хотя эти каталоги уже заданы в настройках виртуального хоста. ИМХО это костыль.
А как бы ты это сделал?
Вообще я не считаю это ошибкой. Если бы я сделал /var с бо́льшим количеством инодов — он бы всего лишь засрал его полностью не так быстро, соответственно я бы обнаружил проблему позже, т.к. визуально всё работает. Моей ошибкой было то, что я ориентировался лишь на сообщения в консольке, а не рылся где-то в ебенях системы в поисках „а вдруг что не так”, да.
Проверил бы существование опции php_admin_value session.save_path в /etc/apache2/sites-enabled/* и, если она есть, брал пути оттуда и вычищал. ИМХО такая конфигурация с виртуальными хостами очень даже распространена. Сейчас же по факту приходится прописывать пути дважды.
Что стоит между тобой и реализацией? Хоть бы баг запостил на багтрекер. Если реализация настолько простая, как ты о ней говоришь, наверное и патч можно замутить.
Что стоит между тобой и реализацией?
Нужно тщательно оттестировать и продумать возможные нюансы. Всё же это удаление данных, потенциально рискованная операция.
XXI век на дворе, а люди все еще сношают мозг количеством инодов…
XXI век на дворе, а люди все еще сношают мозг количеством инодов…
drBatty
И при чём здесь PHP как ЯП? Совсем слака мозг выела.
извиняюсь. Это php выел. И как ЯП дерьмо, и конфиг тоже дерьмо.
Вообще я не считаю это ошибкой. Если бы я сделал /var с бо́льшим количеством инодов — он бы всего лишь засрал его полностью не так быстро, соответственно я бы обнаружил проблему позже, т.к. визуально всё работает.
другая ФС начала-бы просто люто тупить с большим числом файлов в одной «папке». Я проверял.
Моей ошибкой было то, что я ориентировался лишь на сообщения в консольке, а не рылся где-то в ебенях системы в поисках „а вдруг что не так”, да.
как-то ты нехорошо отозвался о почте к администратору, учитывая, что админ — это ты.
кто-то тут, сравнивая ext* и NTFS, всерьёз называл последнюю морально устаревшей ФС из 80-х годов.
так и есть. Попробуй там создать папку с таким количеством файлов. А в EXT4 даже всё работает. Хотя на такой юзкейс, да, требуется ручная настройка или куча места свободного.
Как говорится, в своём глазу бревно невидимо.
ты не знал про inode.
Просто не вижу смысла каждые полчаса рапортовать об очистке каталога.
Если скрипт очищающий сессии в кроне, то всё что он выплюнет на stdout скорее всего будет отправлено в почту.
как-то ты нехорошо отозвался о почте к администратору, учитывая, что админ — это ты.
Как-то нехорошо сделали разработчики, учитывая что изкоробки почта не настроена и далеко не всем нужна. Что им мешало вывести уведомление в консоль во время считывания конфига?
А можно сразу списочек чего еще нужно знать о внутренностях fs что бы ими пользоваться ?
И кому собственно сдавать экзамен по этим самым внутренностям ?
PS: В 21-м веке иметь дистриб без автоматического увеличения inode, это только в linux такое возможно
Дык побочный эффект долбанного униксвея. Типо, если команда выполнена успешно то ничего на экран выводить не нужно. Программы должны молча выполнять своё дело, а если открывать рот то только для ругани. В общем нифига не юзерфрендли.
PS: так что из скриптов сообщения пользователю лучше убрать, чистил, ну или перенаправление в /dev/null
А дефрагментатор, и тот только недавно сделали.
так и есть. Попробуй там создать папку с таким количеством файлов
Там я просто в такую ситуацию не попадал никогда, поэтому даже не знаю зачем это может быть нужно. Сейчас под рукой на NTFS-разделе есть каталог с 9к файлов в нём, не учитывая файлы во вложенных подкаталогах. УМВР.
Возможность засрать все иноды и плеваться отсутствием места, когда его ещё больше половины — это великое достижение 21 века в сфере архитектуры ФС, да.
Знал, именно поэтому сразу же сделал df -i. Я думал что дефолтные параметры адекватны и мне их хватит, поэтому дальше не ковырял.
другая ФС начала-бы просто люто тупить с большим числом файлов в одной «папке». Я проверял
Сделал 50k файлов в одной директории на ext4: 3,0 секунды. Сделал 50k файлов в одной директории на reiserfs: 3,1 секунды. Погрешность измерять лень. Mc заходит в директории с заметной задержкой, но явно меньше секунды.
Очистил кэши, time ls -l > /dev/null на ext4 отрабатывает за 3,5 секунды, на reiserfs — за 1,5 секунды (отклонения порядка +- 0,1 сек). С прогретыми кешами — по 0,7 секунды. Тупить, говоришь?
Сделал tree /var>>var.txt и беглым просмотром обнаружил каталог /var/spool/exim4/input, засранный 42384 файлами с именами типа 1Rvs5t-00052Q-Uv-H
Т.е. ещё и exim криво настроен. Почта в очереди не должна накапливаться. Либо она доставляется, либо отправителю высылается bounce mail о невозможности доставки. А если и bounce не получается доставить, то он молча сбрасывается.
каждые полчаса крон бодро рапортовал об очистке каталогов с сессиями PHP (кстати, как это оповещение отключить?).
man bash. Перенаправь вывод в файл
Ещё плохо то, что в дебиане по умолчанию ничего никуда не перенаправляется, просто торчит вот такой вот скрипт в кроне. Поэтому в случае установки новичком apache+php и правки php.ini для какого-нибудь девелопмента через какое-то время получаем отсутствие инодов в /var (или в /) одновременно с кучей свободного места, засранный в лучшем случае тысячами одинаковых файлов /var/spool/exim4/input с одинаковыми сообщениями и очень удивлённого новичка, не знающего даже в какую сторону копать.
другая ФС начала-бы просто люто тупить с большим числом файлов в одной «папке». Я проверял.
ЛЮТО тупить . При частоте обращений к данной «папке» один раз в ТРИНДАЦАТЬ МИНУТ ?
Какого только бреда от тебя не прочитаешь. LOL
Я его не настраивал вообще, просто отключил демон т.к. он мне ненужен и тормозит систему при загрузке.
хороший у тебя ник. хост в dns забыл внести?
хороший у тебя ник. хост в dns забыл внести?
Чтобы прочитать сообщение об ошибке мне кроме почты нужно ещё и DNS поднимать? Отличное юзерфрендли.
Источник
