Когато започнем да се занимаваме с GNU/Linux, рано или късно се появява една донякъде мистериозна концепция: inodes (индексни дескриптори). Знаем, че те са свързани с това как файловете се съхраняват на диска, че доставчиците на хостинг услуги ги ограничават и че ако се изчерпят, системата се побърква... В тази статия хвърляме малко светлина върху темата, обяснявайки... Какво представляват inodes в Linux? и какво е истинското му значение.
Ние обясняваме Какво точно е inode, какво съхранява, как е организиран на диска?Защо можем да ни свършат, дори когато имаме свободно място, и какви команди имаме, за да ги контролираме?
Какво е inode в Linux?
Иноду (иноду, на индексен възел) е структура от данни на файлова система, която съхранява всички метаданни на файл или директория В Unix-подобни системи (Linux, BSD и др.), всеки обикновен файл, всяка папка и дори някои специални типове обекти (сокети, FIFO, устройства) имат асоцииран inode.
Тозият индексен нос се идентифицира от уникално цяло число във всяка файлова системаТова е известно като „номер на inode“. Това число е това, което ядрото използва вътрешно, за да се обърне към файла; името, което виждате в директорията, всъщност е „етикет“, който сочи към съответния inode.
Важно е да се разбере това Индексният дескриптор не съдържа нито името на файла, нито съдържанието на файлаИмето се съхранява в записа в директорията (в така наречените dentries), а съдържанието се намира в отделни блокове с данни. Индексният възел (in-ode) съхранява всичко останало, от което системата се нуждае, за да локализира и управлява това съдържание.
В рамките на една и съща файлова система (един дял, за опростяване) Не може да има два inode-а с един и същ номерНомерът на inode обаче може да се повтаря в различни файлови системи, защото се идентифицира глобално чрез комбиниране на „устройство“ + „номер на inode“.
Каква информация съхранява един inode?
Индексният дескриптор (in-ode) съдържа почти всички метаданни на файл или директория. С други думи, всичко, което описва файла, освен името му и действителното му съдържаниеСред другите, откриваме:
- Номер на индекс: уникален целочислен идентификатор на inode-а във файловата система.
- Размер на файла в байтове.
- Брой блокове от данните, които файлът заема на диска.
- Идентификатор на устройството (Идентификатор на устройство): на кое устройство/файлова система е записано.
- UID (потребителски идентификатор): идентификатор на потребителя-собственик.
- GID (Идентификатор на група): идентификатор на собственическата група.
- Разрешителни и вид (режим): обикновен файл, директория, връзка, устройство и битовете за четене/запис/изпълнение за собственик, група и други.
- Брой твърди връзки (твърди връзки), свързани с този inode.
- времеви отпечатъциatime (последен достъп), mtime (последна промяна на данните) и ctime (последна промяна на самия inode, например разрешения или собственик).
- Информация за версията или разширени атрибути, в зависимост от файловата система.
- Таблица с указатели към блокове данни, което показва къде физически се намират блоковете, съдържащи съдържанието на файла.
В Linux системите можем да проверим тази информация с командата StatНапример, ако изпълним:
stat archivo.txt
Ще видим изход, където се появят номерът на inode, разрешенията, UID/GID, размера, трите дати и броя на връзките...наред с други полета. Всичко това е основно съдържанието на inode-а, свързан с този файл.
Как работят inodes и блоковете данни
Unix-подобни файлови системи, като ext2/ext3/ext4, XFS, Btrfs или UFS, Те организират диска в блокове с данни с фиксиран размер (4 KB е типично в днешно време). Съдържанието на файловете е разпределено в тези блокове; ако даден файл е голям, той ще заема много блокове, евентуално несъседни.
За да може системата да намери това съдържание, inode-ът включва указатели към блоковете, където се съхранява файлътТова е като книжна карта в библиотека: картата (индексният възел) не съдържа книгата, но ви казва точно къде да я намерите на рафтовете (блоковете с данни).
В ext4, например, класическата структура на резервен inode 15 адресиращи входа:
- 12 директни указателя към блокове данни.
- 1 прост указател за индиректно насочване.
- 1 двоен указател за индирекция.
- 1 троен указател за индирекция.
Лос директни указатели Те сочат директно към блокове, съдържащи файлови данни. Стига файлът да се побира в рамките на тези 12 блока (приблизително 48 KB, ако размерът на блока е 4 KB), достъпът е много бърз, защото inode достига директно до данните.
Когато файлът надвиши този капацитет, се случва следното: проста индиректностУказателят на индексния възел 13 сочи към блок, който не съдържа файлови данни, а по-скоро таблица с повече указатели към блокове с данни. Ако файлът продължи да расте, се използват двойна и тройна индирекция, които свързват нивата на таблиците с указатели, което позволява огромни файлове, до десетки терабайти в ext4, за сметка на повече скокове и малко по-бавен достъп до последните блокове.
От това можем да извлечем две ключови идеи: от една страна, Малките файлове се обработват много ефективно (само директни указатели); от друга страна, гигантските файлове изискват по-високо ниво на индирекция и следователно повече работа, за да се разбере къде се намира всеки блок.
Къде се съхраняват inode-ите на диска?
Индексните дескриптори (INODE) също заемат място на диска. Те не са „магически“: Те са част от самата структура на файловата система.Конкретният начин, по който са поставени, зависи от типа файлова система.
В семейството ext (ext2, ext3, ext4), при създаването на файловата система, дялът се разделя на групи блокове. Всяка група съдържа своя собствена таблица с inode и блокове с данни.Това гарантира, че inodes в една област на диска сочат към близки блокове данни. Това минимизира движенията на главите на механичните дискове и подобрява производителността.
Можем да проверим характеристики като размер на индексния възел, общ брой или колко има в група, използвайки tune2fs, Например:
tune2fs -l /dev/sda1 | grep Inode
Ще ни покаже полета като Брой индексни възли, индексни възли на група, размер на индексния възели т.н. Доста често се срещат размери на inode от 128 или 256 байта в ext2/ext3/ext4, въпреки че други системи използват различни структури.
В други файлови системи, като например ReiserFS, XFS или BtrfsПодходът е различен: не винаги има предварително разпределена „традиционна“ таблица с индексни дескриптори, а по-скоро по-динамични структури, които създават индексни дескриптори при необходимост. Въпреки това, Винаги има някакъв еквивалентен механизъм, който изпълнява същата функция: описва файлове, използвайки метаданни и указатели към данни.
Dentries: как са свързани имената и inodes-ите
Дотук говорихме за inode-и, но липсва ключов елемент: Къде се съхранява името на файла? Това е отговорността на протези (записи в директорията).
Всяка директория поддържа таблица с двойки „име на вход → номер на индексен възел“Тоест, dentry казва „файлът Carta.odt съответства на inode 10043“. Когато го направите ls Или пък отваряте файл по пътя му, ядрото преминава през йерархията на директориите, следвайки тези асоциации от името към inode.
Типичната директория ще включва специални записи: . (точка), която сочи към самата директория, и .. (две двоеточия), които сочат към родителската директория. Тези записи също се управляват с помощта на inodes и помагат за навигиране в йерархичната структура.
Ключът тук е, че Един и същ inode може да има няколко свързани имена в различни denties.Това води до твърди връзки. Обратно, напълно е възможно даден inode да съществува без свързани имена (например, отворен файл, който е бил изтрит) и системата все още ще може да осъществява достъп до него, стига някой процес да го държи отворен.
Твърди връзки и ролята на inodes
В Linux файловете не се препращат вътрешно по техния път или име, а по неговия индексен номерТова позволява много мощна функция: твърди връзки.
Твърдата връзка не е нищо повече от допълнителен запис в директорията, който сочи към същия inodeАко го направите:
ln archivo.txt copia.txt
и двете имена, file.txt y копие.txtТе остават свързани с един и същ inode. Те споделят абсолютно едно и също съдържание и метаданни (с изключение, разбира се, на името на директорията). Ако изтриете един от тях, inode-ът не се изтрива, докато броячът на връзките не достигне нула, защото все още има друго име, което го препраща.
Това коренно контрастира със символните връзки (или преките пътища в Windows): Символичната връзка съдържа пътя до целевия файл като текст. Той има свой собствен inode и метаданни. Ако преименуваме или изтрием действителния файл, символната връзка остава „висяща“. За разлика от това, при твърдите връзки всички имена са еквивалентни; никое не е „по-важно“ от останалите.
Голяма част от гъвкавостта и устойчивостта на файловата система Unix идва именно от това разделение между имена (dentries) и inodesТова прави възможно например да се замени изпълним файл в производствения процес чрез изтриване на стария файл и създаване на нов със същото име, без да се прекъсват процесите, които вече са изпълнявали предишната версия.
Лимитът на инодите и защо може да свърши
Когато създавате файлова система, вие дефинирате Колко индексни възела ще бъдат налични общо?В класическите ext системи, този номер е фиксиран по време на форматирането и не може да бъде променен без пълно пресъздаване на файловата система (което предполага форматиране и следователно загуба на данните, ако не е направено предварително резервно копие).
Често срещано евристично правило в ext2/ext3/ext4 е да се резервира приблизително един inode на 16 KB капацитет. Теоретично, с 32-битови числа, максимумът би бил около 232 inodes (около 4,3 милиарда), но на практика се избира разумна стойност за размера на дяла.
Това има важно последствие: Броят на inodes е краен и може да бъде изчерпан.Точно както дисковото пространство свършва. И освен това е сравнително лесно да ни свършат inodes, когато имаме милиони много малки файлове, дори ако има достатъчно място на дяла.
Представете си диск с няколко милиона свободни inode-и и стотици мегабайта свободно пространство. Ако дадено приложение генерира милиони малки файлове (например имейли, записани по един във файл, временни сесии, ротирани лог файлове, кеш файлове и др.), е възможно това всички inodes са заети, използвайки само няколко мегабайта място за съхранениеСлед като няма налични inode, не могат да се създават нови файлове, дори ако има свободни блокове.
В тази ситуация, когато се опитвате да създадете нови файлове или директории, може да срещнете съобщения като Няма останало място на устройството или виждате, че приложенията се провалят без видима причина, въпреки че командата df все още показва свободно място в GB.
Практически последици от свършването на тоалетните
Когато броячът на индексните възли достигне 100% заетост, системата започва да проявява доста неприятно поведение. Сред типичните проблеми, произтичащи от прекомерна употреба на тоалетни Те са:
- Невъзможност за създаване на нови файлове или директориидори ако има достатъчно свободно място на дяла.
- Приложението се срива или замръзва които се опитват да записват временни файлове и не могат.
- Непланирани рестарти или сривове на системата ако критичните услуги не могат да регистрират или създават файлове за състоянието.
- Неуспех на планирана задача (cronjobs), които трябва да създават работещи файлове.
- Загуба на данни в услуги като пощенски сървъри, ако те не могат да съхраняват нови съобщения.
Това е сценарий, който често се наблюдава в споделени хостинг сървъри, уеб сървъри и имейл сървърикъдето се натрупват милиони малки файлове (кеш, PHP сесии, стари имейли, временни CMS файлове и др.). Ето защо много доставчици на хостинг изрично ограничаване на броя на inodes В допълнение към дисковото пространство: това предотвратява претоварването на системата с милиони малки файлове от един клиент.
Как да проверя използването на inode
Linux предоставя няколко команди за проверете както общия брой inodes, така и тяхното използванекакто и специфичния номер на inode на файл или директория. Това са основни инструменти за всяка системна администрация.
Преглед на свободните и използвани inodes с df -i
Командата df Показва дисково пространство и с опцията -i Вместо това, той показва информация за inode:
df -i
Типичният изход включва колони като Инодове, IUsed, IFree и IUse%в допълнение към точката на монтиране. Чрез сумиране на полетата used и free inode, можем да видим общия брой налични inode във всяка файлова система.
Ако искаме да се фокусираме върху конкретен дял, можем да му предадем устройството или точката на монтиране, например:
df -i /dev/sda1
Това е особено полезно, когато подозираме, че Проблемът „Няма място на устройството“ се дължи на липса на inodes, а не на блокове.Ако IUse% е близо до 100%, вече знаем какво се случва.
Преглед на броя на inode файловете и директориите
За да разберем кой inode използва даден файл, можем да използваме ls с опция -i:
ls -i archivo.txt
Или, за да изброите цяла директория с нейните inode номера:
ls -i
В първата колона ще видим номера на inode, свързан с всяко име. Това е много полезно, когато проучваме. Колко имена сочат към един и същ inode? (твърди връзки) или когато правим кръстосани препратки към информация с ниско ниво помощни програми, които показват само номерата на inode.
Ако се интересуваме от пълната информация за inode-а (дати, разрешения, размер и т.н.), командата Stat Още по-подробно е:
stat /var/log/lastlog
На реда, който гласи „Inode“, ще видим идентификатора, а около него ще се появи класическите метаданни, които inode съхраняваразмер, брой блокове, връзки, UID, GID, режими на достъп и времеви отпечатъци.
Пребройте колко inode-а се използват в дърво на директории
Ако искаме да добием представа колко inode-а консумира една директория и всичко, свързано с нея, можем да комбинираме намерите с тоалетна -л:
find /var/log | wc -l
Полученото число ще бъде броят на записите (файлове и поддиректории) който се намира под този път, тоест приблизителен брой индексни възли, използвани в това конкретно дърво. Много е полезен за локализиране на области от системата, където се натрупват хиляди или милиони малки файлове.
Промяна на броя и размера на inodes (ext4)
В ext4 файловите системи, inode-ите се създават по време на форматирането на дялаСлед като файловата система е създадена, общият брой inode-и и техният размер са фиксирани и не могат да бъдат увеличавани динамично, освен в много специфични случаи (някои разширения с LVM или промяна на файловата система).
При форматиране с mkfs.ext4Можем изрично да укажем колко индексни възела искаме и какъв размер. Например:
sudo mkfs.ext4 -N 2000000 -I 256 /dev/sdX
Тази команда ще създаде файлова система ext4 в /dev/sdX с 2 000 000 inode-а, всеки по 256 байтаВажно е обаче да се имат предвид няколко подробности:
- Размер на индексния възел Трябва да е степен на 2, равна или по-голяма от 128 байта (обикновено 128 или 256).
- Колкото повече inode-и и колкото по-големи са теКолкото повече дисково пространство заема самата файлова система, толкова повече дисково пространство ще използва.
- Не е добра идея да си „играете“ с тези параметри, без наистина да знаете какво правите.защото можем да губим място или да ни свършат индексните йодове.
В повечето случаи, за потребители без много специални нужди, е достатъчно просто да го оставят mkfs.ext4 Определете параметрите по подразбиране:
sudo mkfs.ext4 /dev/sdX
Ако по-късно открием, че на ext4 дял хронично липсват inode-и, практическото решение обикновено включва преоразмеряване или преформатиране (след като направите резервно копие) или мигрирайте към по-гъвкава файлова система, като XFS или Btrfs, която Те не предварително присвояват всички inodes.
Как да открием и решим проблеми с тоалетната
Когато една система започне да проявява странни симптоми (приложения, които се сриват, cron задачи, които не се стартират, привидно случайни грешки), една от първите проверки трябва да бъде използването на индексни дескрипториТипичният диагностичен работен процес е нещо подобно:
Първо проверяваме състоянието на подозрителния дял с:
df -i /punto/de/montaje
Ако процентът на използваните inode е много висок (над 90% и със сигурност ако е 100%), имаме потвърждение, че Проблемът е в броя на inodes, а не в пространството.Оттам нататък решението включва освобождаване на inodes чрез изтриване на файлове.
Типична стратегия е да се намерят директории с много малки файлове. Можем да изброим файловете в директория, сортирани по размер, с:
ls -laShr /ruta
и по този начин да видите с един поглед къде се натрупват хиляди малки файлове, които вероятно вече нямат смисъл (например, стари сесии, кешове, временни файлове, ротирани лог файлове, остарели резервни копия...).
На сървъри, където постоянно се генерират временни или кеш файлове, добра практика е Автоматизирайте изтриването на стари файлове с помощта на cronНапример, можем да изтрием файлове, по-стари от 14 дни в определена директория, с команда find подходящо в периодична cron задача.
Ако след добро почистване все още имаме много малко inode-и или нямаме място за изтриване, единственото реално решение е да преразделете или пресъздайте файловата система с повече inode-иТова е деликатен въпрос, защото включва пълно архивиране и обикновено спиране на услуга. Но когато първоначалният дизайн на файловата система се провали, няма магическо решение, което да „добавя“ inode-и в движение.
Накратко, следете inodes с инструменти като df -i, du, намиране и ls Това е част от рутинните задачи по поддръжката, на същото ниво като наблюдението на свободното пространство или натоварването на процесора.
Разбирането как работят inodes в Linux, какви данни съхраняват и защо са ограничени, помага да се избегнат много проблеми в производството и позволява по-добро оразмеряване на нашите файлови системи. Знаейки, че Всеки файл и директория консумира един inode.Тъй като броят им е дефиниран (в много системи) при създаването на дяла и изчерпването им блокира създаването на нови файлове, дори ако дискът не е пълен, можем да планираме разумно: да изберем подходящата файлова система, да контролираме растежа на малките файлове и да използваме команди за проверка, за да държим винаги под контрол този ресурс, толкова основен, колкото и невидим в ежедневието.