Vše, co jste kdy chtěli vědět o inodech v systému Linux

Souborový systém Linux spoléhá na inody. Tyto životně důležité součásti vnitřního fungování systému souborů jsou často nepochopeny. Pojďme se podívat na to, co přesně jsou a co dělají.

Prvky souborového systému

Podle definice musí souborový systém ukládat soubory a také obsahují adresáře. Soubory jsou uloženy v adresářích a tyto adresáře mohou mít podadresáře. Něco někde musí zaznamenat, kde jsou všechny soubory umístěny v systému souborů, jak se nazývají, ke kterým účtům patří, která oprávnění mají a mnoho dalšího. Tato informace se nazývá metadata, protože jde o data, která popisují další data.

V systému souborů Linux ext4 spolupracují struktury inode a adresáře, aby poskytly základní rámec, který ukládá všechna metadata pro každý soubor a adresář. Dělají metadata k dispozici každému, kdo ji potřebuje, ať už to je jádro, uživatelské aplikace nebo Linux nástrojů, jako jsou ls, stata df.

Inody a velikost systému souborů

I když je pravda, že existuje dvojice struktur, souborový systém vyžaduje mnohem víc. Každá struktura má tisíce a tisíce. Každý soubor a adresář vyžaduje inode a protože každý soubor je v adresáři, vyžaduje každý soubor také adresářovou strukturu. Struktury adresářů se také nazývají položky adresáře nebo „dentries“.

Každý inode má číslo inode, které je jedinečné v systému souborů. Stejné číslo inodu se může objevit ve více než jednom systému souborů. ID systému souborů a číslo inodu se však spojí a vytvoří jedinečný identifikátor bez ohledu na to, kolik systémů souborů je připojeno k vašemu systému Linux.

Nezapomeňte, že v systému Linux nepřipojujete pevný disk nebo oddíl. Připojíte souborový systém, který je na oddílu, takže je snadné mít více souborových systémů, aniž byste si to uvědomovali. Pokud máte na jedné jednotce více pevných disků nebo diskových oddílů, máte více než jeden systém souborů. Mohou být stejného typu - například všechny ext4 - ale stále to budou odlišné souborové systémy.

Všechny inody jsou drženy v jedné tabulce. Pomocí čísla inody souborový systém snadno vypočítá offset do tabulky inodů, ve kterých je tento inode umístěn. Uvidíte, proč „i“ v inode znamená index.

Proměnná, která obsahuje číslo inodu, je ve zdrojovém kódu deklarována jako 32bitové celé číslo bez znaménka. To znamená, že číslo inody je celočíselná hodnota s maximální velikostí 2 ^ 32, která se vypočítá na 4 294 967 295 - tedy více než 4 miliardy inodů.

To je teoretické maximum. V praxi se počet inodů v systému souborů ext4 určuje, když je souborový systém vytvořen s výchozím poměrem jeden inode na 16 kB kapacity systému souborů. Struktury adresářů se vytvářejí za běhu, když se používá systém souborů, protože soubory a adresáře se vytvářejí v systému souborů.

Existuje příkaz, pomocí kterého můžete zjistit, kolik inodů je v systému souborů ve vašem počítači. Možnost -i(inody) dfpříkazu dává pokyn, aby zobrazovala svůj výstup v počtech inodů.

Podíváme se na systém souborů v prvním oddílu na prvním pevném disku, takže zadáme následující:

df -i / dev / sda1

Výstup nám dává:

  • Souborový systém : Souborový systém, o kterém se hlásí.
  • Inody : Celkový počet inodů v tomto systému souborů.
  • IUsed : Počet používaných inodů.
  • IFree : Počet zbývajících inodů dostupných pro použití.
  • IUse% : Procento použitých inodů.
  • Připojeno k : Bod připojení pro tento systém souborů.

V tomto systému souborů jsme použili 10 procent inodů. Soubory jsou uloženy na pevném disku v blocích disků. Každý inode ukazuje na bloky disku, ve kterých je uložen obsah souboru, který představují. Pokud máte miliony drobných souborů, mohou vám dojít inody, než vám dojde místo na pevném disku. To je však velmi obtížný problém.

V minulosti měly tento problém některé poštovní servery, které ukládaly e-mailové zprávy jako samostatné soubory (což rychle vedlo k velkým sbírkám malých souborů). Když však tyto aplikace změnily své zadní konce na databáze, problém se tím vyřešil. Průměrnému domácímu systému nedojdou inody, což je stejně dobře, protože se systémem souborů ext4 nemůžete přidat další inody bez přeinstalace systému souborů.

Chcete-li zobrazit velikost bloků disků ve vašem systému souborů, můžete použít blockdevpříkaz s možností --getbsz(získat velikost bloku):

sudo blockdev --getbsz / dev / sda

Velikost bloku je 4096 bajtů.

Pomocí možnosti -B(velikost bloku) určíme velikost bloku 4096 bajtů a zkontrolujeme běžné využití disku:

df -B 4096 / dev / sda1

Tento výstup nám ukazuje:

  • Systém souborů : Systém souborů, ve kterém vytváříme zprávy.
  • Bloky 4K : Celkový počet bloků 4 KB v tomto systému souborů.
  • Použité : Kolik bloků 4K se používá.
  • Dostupné : Počet zbývajících 4 KB bloků, které jsou k dispozici pro použití.
  • Use% : Procento 4 KB bloků, které byly použity.
  • Připojeno k : Bod připojení pro tento systém souborů.

V našem příkladu úložiště souborů (a úložiště inodů a adresářových struktur) využilo 28 procent prostoru v tomto souborovém systému za cenu 10 procent inodů, takže jsme v dobré kondici.

Inode metadata

Chcete-li zobrazit číslo inode souboru, můžeme použít lss možností -i(inode):

ls -i geek.txt

Číslo inodu pro tento soubor je 1441801, takže tento inode obsahuje metadata pro tento soubor a tradičně ukazatele na bloky disku, kde se soubor nachází na pevném disku. Pokud je soubor fragmentovaný, velmi velký nebo obojí, některé z bloků, na které inode směřuje, mohou obsahovat další ukazatele na další bloky disku. A některé z těchto dalších diskových bloků mohou také obsahovat ukazatele na jinou sadu diskových bloků. To překonává problém, že inode má pevnou velikost a je schopen pojmout konečný počet ukazatelů na bloky disku.

Tuto metodu nahradilo nové schéma, které využívá „rozsahy“. Ty zaznamenávají počáteční a koncový blok každé sady souvislých bloků použitých k uložení souboru. Pokud je soubor nefragmentovaný, musíte uložit pouze první blok a délku souboru. Pokud je soubor fragmentovaný, musíte uložit první a poslední blok každé části souboru. Tato metoda je (samozřejmě) efektivnější.

Pokud chcete zjistit, zda váš systém souborů používá ukazatele nebo rozsahy bloků disku, můžete se podívat dovnitř inodu. K tomu použijeme debugfspříkaz s možností -R(požadavek) a předáme jej inode souboru, který nás zajímá. To požádá  debugfs o použití jeho interního příkazu „stat“ k zobrazení obsahu inode. Protože čísla inod jsou v systému souborů jedinečná, musíme také říct debugfs systému souborů, na kterém je inode umístěn.

Tady vypadá tento příklad příkazu:

sudo debugfs -R "stat" / dev / sda1

Jak je znázorněno níže, debugfspříkaz extrahuje informace z inode a předá nám je v less:

Zobrazují se následující informace:

  • Inode : Číslo inodu, na které se díváme.
  • Typ : Toto je běžný soubor, nikoli adresář nebo symbolický odkaz.
  • Režim : Oprávnění souboru v osmičkovém formátu.
  • Příznaky : Indikátory, které představují různé funkce nebo funkce. 0x80000 je příznak „rozsahu“ (více o tom níže).
  • Generace : Systém NFS (Network File System) to používá, když někdo přistupuje ke vzdáleným systémům souborů přes síťové připojení, jako by byly připojeny k místnímu počítači. Čísla inode a generace se používají jako forma popisovače souborů.
  • Verze : Verze inode.
  • Uživatel : Vlastník souboru.
  • Skupina : Vlastník skupiny souboru.
  • Projekt : Vždy by měl být nula.
  • Velikost : Velikost souboru.
  • File ACL : Seznam řízení přístupu k souborům. Byly navrženy tak, aby vám umožňovaly umožnit kontrolovaný přístup lidem, kteří nejsou ve skupině vlastníků.
  • Odkazy : Počet pevných odkazů na soubor.
  • Počet bloků : Množství místa na pevném disku přidělené tomuto souboru, dané v blocích 512 bajtů. Náš soubor má přiděleno osm z nich, což je 4096 bajtů. Náš 98bajtový soubor tedy leží v jediném 4 096 bajtovém bloku disku.
  • Fragment : Tento soubor není fragmentovaný. (Toto je zastaralý příznak.)
  • Ctime : Čas, kdy byl soubor vytvořen.
  • Atime : Čas, kdy byl tento soubor naposledy zpřístupněn.
  • Mtime : Čas, kdy byl tento soubor naposledy upraven.
  • Crtime : Čas, kdy byl soubor vytvořen.
  • Velikost dalších polí inode : Souborový systém ext4 zavedl možnost alokovat větší inode na disku v době formátování. Tato hodnota je počet dalších bajtů, které inode používá. Tento prostor navíc lze také použít k uspokojení budoucích požadavků na nová jádra nebo k uložení rozšířených atributů.
  • Kontrolní součet inode: Kontrolní součet pro tento inode, který umožňuje zjistit, zda je inode poškozen.
  • Rozsahy : Pokud se používají rozsahy (na ext4 jsou ve výchozím nastavení), metadata týkající se využití bloků disku na discích mají dvě čísla, která označují počáteční a koncový blok každé části fragmentovaného souboru. To je efektivnější než ukládání každého bloku disku, který zabírá každá část souboru. Máme jeden rozsah, protože náš malý soubor sedí v jednom diskovém bloku s tímto offsetem bloku.

Kde je název souboru?

Nyní máme o souboru spoustu informací, ale jak jste si mohli všimnout, název souboru jsme nezjistili. Zde vstupuje do hry adresářová struktura. V Linuxu má adresář stejně jako soubor inode. Spíše než ukazovat na bloky disku, které obsahují data souborů, adresář inode ukazuje na bloky disku, které obsahují adresářové struktury.

Ve srovnání s inodem obsahuje adresářová struktura omezené množství informací o souboru. Obsahuje pouze číslo inodu souboru, název a délku názvu.

Inode a adresářová struktura obsahují vše, co (nebo aplikace) potřebujete o souboru nebo adresáři vědět. Struktura adresářů je v bloku adresářových disků, takže víme, v jakém adresáři je soubor. Struktura adresářů nám dává název souboru a číslo inodu. Inode nám říká vše ostatní o souboru, včetně časových razítek, oprávnění a kde najít data souboru v systému souborů.

Inodes adresáře

Číslo inode adresáře vidíte stejně snadno jako u souborů.

V následujícím příkladu použijeme ls s možnostmi -l(dlouhý formát), -i(inode) a -d(adresář) a podíváme se na workadresář:

ls -lid práce /

Protože jsme použili možnost -d(adresář),  lshlásí se samotný adresář, nikoli jeho obsah. Inode pro tento adresář je 1443016.

Chcete-li to zopakovat pro homeadresář, zadejte následující:

Je-víčko ~

homeInode pro adresář je 1447510 a workadresář je v domovském adresáři. Nyní se podívejme na obsah workadresáře. Místo možnosti  -d(adresář) použijeme možnost -a(vše). Tím se nám zobrazí položky adresáře, které jsou obvykle skryté.

Zadáme následující:

ls -lia práce /

Protože jsme použili možnost -a(vše), jsou zobrazeny položky s jednou (.) A dvojitou tečkou (..). Tyto položky představují samotný adresář (jedna tečka) a její nadřazený adresář (dvojitá tečka).

Když se podíváte na číslo inode pro položku s jednou tečkou, zjistíte, že je to 1443016 - stejné číslo inode, které jsme dostali, když jsme objevili číslo inode pro workadresář. Také číslo inode pro zadání dvojitých teček je stejné jako číslo inode pro homeadresář.

Proto můžete pomocí cd ..příkazu přesunout o úroveň výš v adresářovém stromu. Podobně, když předcházíte názvu aplikace nebo skriptu   ./, dáte shellu vědět, odkud má aplikaci nebo skript spustit.

Inody a odkazy

Jak jsme již uvedli, pro vytvoření dobře přístupného souboru v systému souborů jsou vyžadovány tři komponenty: soubor, adresářová struktura a inode. Soubor jsou data uložená na pevném disku, adresářová struktura obsahuje název souboru a jeho číslo inodu a inode obsahuje všechna metadata souboru.

Symbolické odkazy jsou položky systému souborů, které vypadají jako soubory, ale jsou to opravdu zkratky, které odkazují na existující soubor nebo adresář. Podívejme se, jak to zvládají a jak se k dosažení tohoto cíle používají tři prvky.

Řekněme, že máme adresář se dvěma soubory: jeden je skript a druhý je aplikace, jak je znázorněno níže.

Můžeme použít příkaz ln a -s(symbolickou) volbu k vytvoření měkkého odkazu na soubor skriptu, například:

je můj_script geek.sh

Vytvořili jsme odkaz na my_script.shvolané geek.sh. Můžeme zadat následující a použít  ls se podívat na dva soubory skriptu:

ls -li * .sh

Položka pro se geek.sh zobrazí modře. První znak příznaků oprávnění je „l“ pro odkaz a  ->ukazuje na my_script.sh. To vše naznačuje, že geek.shjde o odkaz.

Jak pravděpodobně očekáváte, dva soubory skriptu mají různá čísla inodů. Co by však mohlo být překvapivější, je měkký odkaz geek.sh, nemá stejná uživatelská oprávnění jako původní soubor skriptu. Ve skutečnosti jsou oprávnění pro  geek.shmnohem liberálnější - všichni uživatelé mají úplná oprávnění.

Struktura adresáře pro geek.shobsahuje název odkazu a jeho inode. Když se pokusíte použít odkaz, odkazuje se na jeho inode, stejně jako na běžný soubor. Inode odkazu bude směřovat na blok disku, ale místo toho, aby obsahoval data obsahu souboru, blok disku obsahuje název původního souboru. Souborový systém přesměruje na původní soubor.

Odstraníme původní soubor a uvidíme, co se stane, když zadáme následující pro zobrazení obsahu  geek.sh:

rm my_script.sh
kočka geek.sh

Symbolický odkaz je přerušený a přesměrování selže.

Nyní vytvoříme následující odkaz, abychom vytvořili pevný odkaz na soubor aplikace:

Ve speciální aplikaci geek-app

Chcete-li se podívat na inody pro tyto dva soubory, zadáme následující:

ls -li

Oba vypadají jako běžné soubory. Nic o tom geek-appnenaznačuje, že jde o odkaz ve způsobu, jakým to udělal lsvýpis geek.sh. Navíc  geek-app má stejná uživatelská oprávnění jako původní soubor. Co by však mohlo být překvapivé, je, že obě aplikace mají stejné číslo inodu: 1441797.

Položka adresáře pro geek-appobsahuje název „geek-app“ a číslo inode, ale je to stejné jako číslo inode původního souboru. Takže máme dvě položky systému souborů s různými názvy, které oba ukazují na stejný inode. Ve skutečnosti může libovolný počet položek ukazovat na stejný inode.

Napište následující a pomocí statprogramu se podíváme na cílový soubor:

stat speciální aplikace

Vidíme, že na tento soubor směřují dva pevné odkazy. To je uloženo v inode.

V následujícím příkladu odstraníme původní soubor a pokusíme se použít odkaz s tajným zabezpečeným heslem:

rm speciální aplikace
./geek-app opravte svorku baterie

Překvapivě aplikace běží podle očekávání, ale jak? Funguje to, protože když odstraníte soubor, inode se může znovu použít. Struktura adresářů je označena jako mající nulový počet inodů a bloky disku jsou poté k dispozici pro uložení dalšího souboru v tomto prostoru.

Pokud je počet pevných odkazů na inode větší než jedna, počet pevných odkazů se sníží o jednu a počet inode v adresářové struktuře odstraněného souboru je nastaven na nulu. Obsah souboru na pevném disku a inode je stále k dispozici pro existující pevné odkazy.

Napíšeme následující a použijeme stat ještě jednou - tentokrát geek-app:

aplikace stat geek

Tyto podrobnosti jsou staženy ze stejného inodu (1441797) jako předchozí statpříkaz. Počet odkazů byl snížen o jednu.

Protože jsme na jednom pevném odkazu na tento inode, odstraníme-li  geek-app, skutečně by soubor odstranil. Souborový systém uvolní inode a označí adresářovou strukturu nulovým inodem. Nový soubor pak může přepsat úložiště dat na pevném disku.

SOUVISEJÍCÍ: Jak používat příkaz stat v systému Linux

Inode režie

je to elegantní systém, ale existují režijní náklady. Chcete-li číst soubor, musí souborový systém provést všechny následující kroky:

  • Najděte správnou adresářovou strukturu
  • Přečtěte si číslo inode
  • Najděte správný inode
  • Přečtěte si inode informace
  • Postupujte podle odkazů inode nebo podle rozsahu příslušných bloků disku
  • Přečtěte si data souboru

Pokud jsou data nesouvislá, je nutné trochu více skákat.

Představte si práci, kterou je třeba udělat, aby bylo  ls možné provést dlouhodobý výpis souborů mnoha souborů. Existuje spousta tam a zpět jen pro lszískání informací potřebných pro generování jeho výstupu.

Zrychlení přístupu k souborovému systému je samozřejmě důvodem, proč se Linux snaží dělat co nejvíce preventivního ukládání souborů do mezipaměti. To velmi pomáhá, ale někdy - stejně jako u jiného souborového systému - mohou být zřejmé režijní náklady.

Nyní budete vědět proč.