Всичко, което някога сте искали да знаете за инодите в Linux

Файловата система Linux разчита на inodes. Тези жизненоважни части от вътрешната работа на файловата система често се разбират погрешно. Нека да разгледаме какви точно са те и какво правят.

Елементите на файловата система

По дефиниция файловата система трябва да съхранява файлове и те също съдържат директории. Файловете се съхраняват в директориите и тези директории могат да имат поддиректории. Нещо, някъде, трябва да записва къде се намират всички файлове във файловата система, как се наричат, към кои акаунти принадлежат, кои разрешения имат и много други. Тази информация се нарича метаданни, защото данните описват други данни.

Във файловата система Linux ext4 структурите на inode и директориите работят заедно, за да осигурят основна рамка, която съхранява всички метаданни за всеки файл и директория. Те правят достъпна за всеки, метаданни, който го изисква, независимо дали това е ядрото, потребителски приложения, нито Linux комунални услуги, като например ls, statи df.

Inodes и размер на файловата система

Въпреки че е вярно, че има двойка структури, файловата система изисква много повече от това. Има хиляди и хиляди от всяка структура. Всеки файл и директория изисква inode и тъй като всеки файл е в директория, всеки файл също изисква структура на директория. Структурите на директориите се наричат ​​още записи в директории или „зъболекари“.

Всеки inode има номер на inode, който е уникален във файловата система. Същият номер на inode може да се появи в повече от една файлова система. Идентификаторът на файловата система и номерът на inode обаче се комбинират, за да направят уникален идентификатор, независимо от това колко файлови системи са монтирани на вашата Linux система.

Не забравяйте, че в Linux не монтирате твърд диск или дял. Монтирате файловата система, която е на дяла, така че е лесно да имате множество файлови системи, без да осъзнавате. Ако имате множество твърди дискове или дялове на едно устройство, имате повече от една файлова система. Те може да са от един и същи тип - всички ext4 например - но все пак ще бъдат отделни файлови системи.

Всички иноди се съхраняват в една таблица. Използвайки номер на inode, файловата система лесно изчислява отместването в таблицата на inode, в която се намира този inode. Можете да видите защо „i“ в inode означава индекс.

Променливата, която съдържа номера на inode, е декларирана в изходния код като 32-битово, неподписано дълго цяло число. Това означава, че броят на inode е цяло число с максимален размер 2 ^ 32, което се изчислява на 4 294 967 295 - много над 4 милиарда inode.

Това е теоретичният максимум. На практика броят на инодите във файлова система ext4 се определя, когато файловата система се създава при съотношение по подразбиране от един инод на 16 KB капацитет на файловата система. Структурите на директориите се създават в движение, когато се използва файловата система, тъй като файловете и директориите се създават във файловата система.

Има команда, която можете да използвате, за да видите колко inode са във файлова система на вашия компютър. Опцията -i(inodes) на dfкомандата я инструктира да показва изхода си в брой inodes.

Ще разгледаме файловата система на първия дял на първия твърд диск, така че въвеждаме следното:

df -i / dev / sda1

Резултатът ни дава:

  • Файлова система : Файловата система, за която се докладва.
  • Inodes : Общият брой на inodes в тази файлова система.
  • IUsed : Броят на използваните inode .
  • IFree : Броят на останалите иноди, налични за употреба.
  • IUse% : Процентът на използваните иноди.
  • Монтиран върху : Точката на монтиране за тази файлова система.

Използвали сме 10 процента от инодите в тази файлова система. Файловете се съхраняват на твърдия диск в дискови блокове. Всеки inode сочи към дисковите блокове, които съхраняват съдържанието на файла, който представляват. Ако имате милиони малки файлове, можете да свършите inode, преди да останете без място на твърдия диск. Това обаче е много труден проблем.

В миналото някои пощенски сървъри, които съхраняваха имейл съобщения като дискретни файлове (което бързо доведе до големи колекции от малки файлове), имаха този проблем. Когато тези приложения промениха своите задни краища на бази данни, това реши проблема. Средната домашна система няма да свърши inodes, което е също толкова добре, защото с файловата система ext4 не можете да добавите повече inodes без да преинсталирате файловата система.

За да видите размера на дисковите блокове във вашата файлова система, можете да използвате blockdevкомандата с опцията --getbsz(получи размер на блока):

sudo blockdev --getbsz / dev / sda

Размерът на блока е 4096 байта.

Нека използваме опцията -B(размер на блока), за да посочим размер на блока от 4096 байта и да проверим редовната употреба на диска:

df -B 4096 / dev / sda1

Този изход ни показва:

  • Файлова система : Файловата система , за която докладваме.
  • 4K-блокове : Общият брой от 4 KB блока в тази файлова система.
  • Използвано : Колко 4K блока се използват.
  • Налично : Броят на останалите 4 KB блока, които са достъпни за използване.
  • Използване% : Процентът от 4 KB блокове, които са били използвани.
  • Монтиран върху : Точката на монтиране за тази файлова система.

В нашия пример съхранението на файлове (и съхранението на инодите и структурите на директории) е използвало 28 процента от пространството в тази файлова система, на цената на 10 процента от инодите, така че сме в добра форма.

Метаданни на Inode

За да видим номера на inode на файл, можем да използваме lsс опцията -i(inode):

ls -i geek.txt

Номерът на inode за този файл е 1441801, така че този inode съдържа метаданните за този файл и, традиционно, указателите към дисковите блокове, където файлът се намира на твърдия диск. Ако файлът е фрагментиран, много голям или и двата, някои от блоковете, към които сочи inode, може да съдържат допълнителни указатели към други дискови блокове. И някои от тези други дискови блокове също могат да съдържат указатели към друг набор от дискови блокове. Това преодолява проблема с това, че inode е с фиксиран размер и може да задържи ограничен брой указатели към дискови блокове.

Този метод беше заменен от нова схема, която използва „степени“. Те записват началния и крайния блок на всеки набор от непрекъснати блокове, използвани за съхраняване на файла. Ако файлът е нефрагментиран, трябва да съхраните само първия блок и дължината на файла. Ако файлът е фрагментиран, трябва да съхраните първия и последния блок на всяка част от файла. Този метод е (очевидно) по-ефективен.

Ако искате да видите дали вашата файлова система използва указатели на дискови блокове или разширения, можете да погледнете вътре в inode. За целта ще използваме debugfsкомандата с опцията -R(request) и ще й предадем inode на файла, който ни интересува. Това иска  debugfs да използва вътрешната си команда "stat", за да покаже съдържанието на inode. Тъй като номерата на inode са уникални само във файловата система, трябва да кажем и debugfs на файловата система, в която се намира inode.

Ето как би изглеждала тази примерна команда:

sudo debugfs -R "stat" / dev / sda1

Както е показано по-долу, debugfsкомандата извлича информацията от inode и ни я представя в less:

Показва ни се следната информация:

  • Inode : Номерът на inode, който разглеждаме.
  • Тип : Това е обикновен файл, а не директория или символна връзка.
  • Режим : Разрешенията за файла в осмица.
  • Флагове : Индикатори, които представляват различни характеристики или функционалност. 0x80000 е флагът „extents“ (повече за това по-долу).
  • Поколение : Мрежова файлова система (NFS) използва това, когато някой осъществява достъп до отдалечени файлови системи през мрежова връзка, сякаш е монтиран на локалната машина. Номерите на inode и поколението се използват като форма на манипулатор на файл.
  • Версия : Версията на inode.
  • Потребител : Собственикът на файла.
  • Група : Собственикът на групата на файла.
  • Проект : Винаги трябва да е нула.
  • Размер : Размерът на файла.
  • Файл ACL : Списъкът за контрол на достъпа до файлове. Те са създадени, за да ви позволят да дадете контролиран достъп на хора, които не са в групата на собствениците.
  • Връзки : Броят на твърдите връзки към файла.
  • Блокиране : Количеството място на твърдия диск, разпределено за този файл, дадено в 512-байтови парчета. На нашия файл са разпределени осем от тях, което е 4 096 байта. И така, нашият 98-байтов файл се намира в рамките на един 4 096-байтов дисков блок.
  • Фрагмент : Този файл не е фрагментиран. (Това е остаряло знаме.)
  • Ctime : Времето, в което е създаден файлът.
  • Atime : Часът, в който последният достъп до този файл е бил последен.
  • Mtime : Часът, в който последно е променен този файл.
  • Време на работа : Времето, в което файлът е създаден.
  • Размер на допълнителните полета на inode : Файловата система ext4 въведе възможността да разпределя по-голям inode на диска по време на форматиране. Тази стойност е броят на допълнителните байтове, които използва inode. Това допълнително пространство може да се използва и за приспособяване на бъдещи изисквания за нови ядра или за съхраняване на разширени атрибути.
  • Контролна сума на Inode : Контролна сума за този inode, която дава възможност да се открие дали inode е повреден.
  • Разширения : Ако се използват разширения (на ext4, те са по подразбиране), метаданните относно използването на файловете на дисковия блок имат две числа, които показват началния и крайния блок на всяка част от фрагментиран файл. Това е по-ефективно от съхраняването на всеки диск, зает от всяка част на файл. Имаме една степен, защото нашият малък файл се намира в един дисков блок при това отместване на блока.

Къде е името на файла?

Сега имаме много информация за файла, но, както може би сте забелязали, не получихме името на файла. Тук влиза в сила структурата на директориите. В Linux, точно като файл, директорията има inode. Вместо да сочи към дискови блокове, които съдържат файлови данни, директория inode сочи към дискови блокове, които съдържат структури от директории.

В сравнение с inode, структурата на директориите съдържа ограничено количество информация за файл. Той съдържа само номера на файла, името и дължината на името на файла.

Inode и структурата на директориите съдържат всичко, което вие (или приложение) трябва да знаете за файл или директория. Структурата на директорията се намира в дисков блок на директория, така че знаем директорията, в която се намира файлът. Структурата на директорията ни дава името на файла и номера на inode. Inode ни казва всичко останало за файла, включително времеви марки, разрешения и къде да намерим файловите данни във файловата система.

Каталог Inodes

Можете да видите номера на inode в директорията точно толкова лесно, колкото можете да ги видите за файлове.

В следващия пример ще използваме ls с опциите -l(дълъг формат), -i(inode) и -d(директория) и ще разгледаме workдиректорията:

ls -lid работа /

Тъй като използвахме опцията -d(директория),  lsотчети за самата директория, а не за нейното съдържание. Inode за тази директория е 1443016.

За да повторим това за homeдиректорията, въвеждаме следното:

ls -lid ~

homeInode за директорията е 1447510, а workдиректорията е в домашната директория. Сега, нека разгледаме съдържанието на workдиректорията. Вместо опцията  -d(директория) ще използваме опцията -a(всички). Това ще ни покаже записите в директорията, които обикновено са скрити.

Въвеждаме следното:

ls -lia работа /

Тъй като използвахме опцията -a(всички), се показват записите с една (.) И с две точки (..). Тези записи представляват самата директория (с една точка) и нейната родителска директория (с две точки)

Ако погледнете номера на inode за записа с една точка, ще видите, че това е1443016 - същия номер на inode, който получихме, когато открихме номера на inode за workдиректорията. Също така, номерът на inode за записа с двойна точка е същият като номера на inode за homeдиректорията.

Ето защо можете да използвате cd ..командата, за да се придвижите нагоре на ниво в дървото на директориите. По същия начин, когато предхождате име на приложение или скрипт с   ./, вие уведомявате черупката от къде да стартира приложението или скрипта.

Inodes и връзки

Както разгледахме, три компонента трябва да имат добре оформен и достъпен файл във файловата система: файлът, структурата на директориите и inode. Файлът е данните, съхранявани на твърдия диск, структурата на директориите съдържа името на файла и неговия номер на inode, а inode съдържа всички метаданни за файла.

Символните връзки са записи на файловата система, които приличат на файлове, но те наистина са преки пътища, които сочат към съществуващ файл или директория. Нека да видим как те управляват това и как трите елемента се използват за постигане на това.

Да приемем, че имаме директория с два файла в нея: единият е скрипт, а другият е приложение, както е показано по-долу.

Можем да използваме командата ln и опцията -s(символична), за да създадем мека връзка към файла на скрипта, по следния начин:

ls -s my_script geek.sh

Създадохме връзка към my_script.shcall geek.sh. Можем да напишем следното и да използваме, за  ls да разгледаме двата скрипта:

ls -li * .sh

Записът за се geek.sh появява в синьо. Първият символ на флаговете за разрешения е „l“ за връзка и  ->сочи към my_script.sh. Всичко това показва, че това geek.shе връзка.

Както вероятно очаквате, двата файла със скриптове имат различни номера на inode. Това, което може да е по-изненадващо обаче, е меката връзка geek.sh,, няма същите потребителски разрешения като оригиналния файл на скрипта. Всъщност разрешенията за  geek.shса много по-либерални - всички потребители имат пълни разрешения.

Структурата на директорията за geek.shсъдържа името на връзката и нейния inode. Когато се опитате да използвате връзката, нейният inode се препраща, точно като обикновен файл. Връзката inode ще сочи към дисков блок, но вместо да съдържа данни за съдържанието на файла, той съдържа името на оригиналния файл. Файловата система пренасочва към оригиналния файл.

Ще изтрием оригиналния файл и ще видим какво се случва, когато напишем следното, за да видим съдържанието на  geek.sh:

rm my_script.sh
котка отрепка.ш

Символичната връзка е прекъсната и пренасочването е неуспешно.

Сега въвеждаме следното, за да създадем твърда връзка към файла на приложението:

В специалното приложение geek-app

За да разгледаме инодите за тези два файла, въвеждаме следното:

ls -li

И двете изглеждат като обикновени файлове. Нищо за не geek-appпоказва, че това е връзка в начина, по който lsлистингът geek.shнаправи. Освен това  geek-app има същите потребителски разрешения като оригиналния файл. Това, което обаче може да е изненадващо, е, че и двете приложения имат еднакъв номер на inode: 1441797.

Записът в директорията за geek-appсъдържа името „geek-app“ и номер на inode, но е същото като номера на inode на оригиналния файл. И така, имаме два записа във файловата система с различни имена, които и двамата сочат към един и същ inode. Всъщност произволен брой елементи могат да сочат към един и същ inode.

Ще напишем следното и ще използваме statпрограмата, за да разгледаме целевия файл:

stat специално приложение

Виждаме, че две твърди връзки сочат към този файл. Това се съхранява в inode.

В следващия пример изтриваме оригиналния файл и се опитваме да използваме връзката с тайна, сигурна парола:

rm специално приложение
./geek-app правилно horsebatterystaple

Изненадващо, приложението работи както се очаква, но как? Работи, защото когато изтриете файл, inode може да се използва повторно. Структурата на директорията е маркирана като номер на inode нула и след това дисковите блокове са достъпни за друг файл, който да се съхранява в това пространство.

Ако броят на твърдите връзки към inode е по-голям от един, броят на твърдите връзки се намалява с един и номерът на inode на структурата на директориите на изтрития файл е зададен на нула. Съдържанието на файла на твърдия диск и inode все още е достъпно за съществуващите твърди връзки.

Ще напишем следното и ще използваме stat още веднъж - този път на geek-app:

stat geek-app

Тези подробности се извличат от същия inode (1441797) като предишната statкоманда. Броят на връзките беше намален с един.

Тъй като стигаме до една твърда връзка към този inode, ако изтрием  geek-app, той наистина ще изтрие файла. Файловата система ще освободи inode и ще маркира структурата на директориите с inode нула. След това нов файл може да презапише хранилището за данни на твърдия диск.

СВЪРЗАНИ: Как да използвам командата stat на Linux

Inode режийни разходи

това е чиста система, но има режийни разходи. За да прочете файл, файловата система трябва да направи всичко следното:

  • Намерете правилната структура на директориите
  • Прочетете номера на inode
  • Намерете правилния inode
  • Прочетете информацията за inode
  • Следвайте връзките inode или екстентите към съответните дискови блокове
  • Прочетете данните на файла

Необходимо е малко повече прескачане, ако данните не са съседни.

Представете си работата, която трябва да се свърши, за  ls да се извърши дългоформатен списък с много файлове. Има много напред и назад само за lsда получите информацията, от която се нуждае, за да генерира своята продукция.

Разбира се, ускоряването на достъпа до файловата система е причината Linux да се опитва да направи възможно най-много превантивно кеширане на файлове. Това помага много, но понякога - както при всяка файлова система - режийните разходи могат да станат очевидни.

Сега ще разберете защо.