Minden, amit valaha is tudni akartál az inodesről a Linuxon

A Linux fájlrendszer inodesekre támaszkodik. A fájlrendszer belső működésének ezeket a létfontosságú elemeit gyakran félreértik. Nézzük meg pontosan, hogy mik ők, és mit csinálnak.

A fájlrendszer elemei

Definíció szerint a fájlrendszernek fájlokat kell tárolnia, és könyvtárakat is tartalmaznak. A fájlok a könyvtárakban vannak tárolva, és ezek a könyvtárak lehetnek alkönyvtárakkal. Valaminek, valahol fel kell jegyeznie, hogy az összes fájl hol található a fájlrendszerben, hogyan hívják őket, melyik fiókhoz tartoznak, mely jogosultságokkal rendelkeznek, és még sok minden mást. Ezeket az információkat metaadatoknak nevezzük, mivel ezek más adatokat írnak le.

A Linux ext4 fájlrendszerben az inode és a könyvtárstruktúra együttesen létrehoz egy megalapozó keretrendszert, amely minden fájl és könyvtár összes metaadatát tárolja. Azt, hogy a metaadat elérhető bárki számára, aki igényli azt, hogy ez a kernel, a felhasználói alkalmazások, vagy Linux segédprogramok, mint például ls, statés df.

Inodes és fájlrendszer mérete

Bár igaz, hogy van egy pár struktúra, a fájlrendszer ennél sokkal többet igényel. Ezer és ezer darab van egy-egy struktúrából. Minden fájlhoz és könyvtárhoz inode szükséges, és mivel minden fájl egy könyvtárban van, minden fájlhoz könyvtárstruktúra is szükséges. A címtárszerkezeteket más néven könyvtárbejegyzéseknek vagy „fogsoroknak” is nevezik.

Minden inódnak van egy inode száma, amely egyedi egy fájlrendszeren belül. Ugyanaz az inode-szám több fájlrendszerben is megjelenhet. A fájlrendszer azonosítója és az inode száma azonban egyedi azonosítóvá válik, függetlenül attól, hogy hány fájlrendszer van felhelyezve a Linux rendszerére.

Ne feledje, hogy Linux alatt nem csatlakoztat merevlemezt vagy partíciót. Csatlakoztatja a partíción található fájlrendszert, így könnyen kezelhető több fájlrendszer anélkül, hogy észrevenné. Ha egy merevlemezen több merevlemez vagy partíció van, akkor egynél több fájlrendszerrel rendelkezik. Lehet, hogy azonos típusúak - például az összes ext4 -, de akkor is külön fájlrendszerek lesznek.

Az összes inód egy táblában van. Inode szám felhasználásával a fájlrendszer könnyen kiszámítja az eltolást az inode táblában, ahol az adott inode található. Láthatja, hogy az inode „i” -je miért jelenti az indexet.

Az inode számot tartalmazó változót a forráskód 32 bites, előjel nélküli hosszú egészként deklarálja. Ez azt jelenti, hogy az inode száma egy egész szám, amelynek maximális mérete 2 ^ 32, ami 4 294 967 295-re - azaz jóval több mint 4 milliárd inódra - számít.

Ez az elméleti maximum. A gyakorlatban az ext4 fájlrendszer inódjainak számát akkor határozzák meg, amikor a fájlrendszert alapértelmezetten egy inode / 16 KB fájlrendszer-kapacitás arányban hozzák létre. A címtárstruktúrák menet közben jönnek létre, amikor a fájlrendszert használják, mivel a fájlok és könyvtárak a fájlrendszeren belül jönnek létre.

Van egy parancs, amellyel megtudhatja, hogy hány inode van a számítógép fájlrendszerében. A parancs -i(inodes) opciója arra dfutasítja, hogy a kimenetét inode számban jelenítse meg.

Meg fogjuk vizsgálni az első merevlemez első partíciójának fájlrendszerét, ezért a következőket írjuk be:

df -i / dev / sda1

A kimenet:

  • Fájlrendszer : A fájlrendszer, amelyről jelentést készítenek.
  • Inodes : Az inodes összes száma ebben a fájlrendszerben.
  • IUsed : A használt inódok száma.
  • IFree : A fennmaradó használható inódok száma.
  • IUse% : A felhasznált inódok százalékos aránya.
  • Felszerelve : A fájlrendszer csatlakoztatási pontja.

Az inode-ok 10 százalékát használtuk fel ebben a fájlrendszerben. A fájlokat a merevlemezen lemezblokkokban tárolják. Minden inode az általuk képviselt fájl tartalmát tároló lemezblokkokra mutat. Ha milliónyi apró fájlja van, akkor kifogyhat az inode-okból, mielőtt elfogyna a merevlemez-hely. Ez azonban nagyon nehéz probléma.

A múltban néhány olyan e-mail szerveren, amely különálló fájlként tárolta az e-mail üzeneteket (ami gyorsan kis fájlok nagy gyűjteményéhez vezetett), ez a probléma merült fel. Amikor ezek az alkalmazások hátuljukat adatbázisokra cserélték, ez megoldotta a problémát. Az átlagos otthoni rendszerben nem fogynak el az inódok, ami azért is jó, mert az ext4 fájlrendszerrel nem adhat hozzá több inódot a fájlrendszer újratelepítése nélkül.

A fájlrendszer lemezblokkjainak méretének megtekintéséhez használhatja a blockdevparancsot a --getbsz(blokkméret beolvasása ) opcióval:

sudo blockdev --getbsz / dev / sda

A blokk mérete 4096 bájt.

Használjuk a -B(blokkméret) opciót 4096 bájtos blokkméret megadásához, és ellenőrizzük a rendszeres lemezhasználatot:

df -B 4096 / dev / sda1

Ez a kimenet megmutatja:

  • Fájlrendszer : Az a fájlrendszer, amelyről jelentést készítünk.
  • 4K-blokkok : A 4 KB-os blokkok teljes száma ebben a fájlrendszerben.
  • Használt : Hány 4K blokk van használatban.
  • Elérhető : A még rendelkezésre álló 4 KB-os blokkok száma.
  • Használat% : A használt 4 KB-os blokkok százalékos aránya.
  • Felszerelve : A fájlrendszer csatlakoztatási pontja.

Példánkban a fájlok tárolása (és az inodes és a könyvtárstruktúrák tárolása) a fájlrendszerben a hely 28 százalékát használta fel, az inodes 10 százalékának árán, tehát jó állapotban vagyunk.

Inode metaadatok

A fájl inode számának megtekintéséhez használhatjuk lsaz -i(inode) opciót:

ls -i geek.txt

Ennek a fájlnak az inode-száma 1441801, tehát ez az inode tartalmazza a fájl metaadatait és hagyományosan a merevlemezen található fájlblokkokra mutató mutatókat. Ha a fájl töredezett, nagyon nagy, vagy mindkettő, akkor az inode néhány blokkja további mutatókat tarthat más lemezblokkokhoz. A többi lemezblokk közül néhányan mutatókat is tartalmazhatnak egy másik lemezblokk-készletre. Ez kiküszöböli azt a problémát, hogy az inode rögzített méretű és véges számú mutatót képes tartani a lemezblokkokhoz.

Ezt a módszert felváltotta egy új rendszer, amely „kiterjedéseket” használ. Ezek rögzítik a fájl tárolásához használt minden egyes szomszédos blokk kezdetét és végét. Ha a fájl nem töredezett, akkor csak az első blokkot és a fájl hosszát kell tárolnia. Ha a fájl töredezett, akkor a fájl minden részének első és utolsó blokkját el kell tárolnia. Ez a módszer (nyilván) hatékonyabb.

Ha meg szeretné tudni, hogy a fájlrendszere lemezblokk-mutatókat vagy kiterjedéseket használ-e, akkor belenézhet egy inode belsejébe. Ehhez a debugfsparancsot a -R(kérés) opcióval együtt használjuk, és továbbítjuk az érdekes fájl inode-ját. Ez arra kéri  debugfs , hogy a belső „stat” paranccsal jelenítse meg az inode tartalmát. Mivel az inode számok csak egy fájlrendszeren belül egyediek, meg kell mondanunk azt debugfs a fájlrendszert is, amelyen az inode található.

Így néz ki ez a példa parancs:

sudo debugfs -R "stat" / dev / sda1

Amint az alább látható, a debugfsparancs kivonja az információkat az inode-ból és bemutatja nekünk less:

A következő információkat mutatjuk be:

  • Inode : Az inode száma, amelyet nézünk.
  • Típus : Ez egy rendes fájl, nem könyvtár vagy szimbolikus link.
  • Mód : A fájl engedélyei oktális formában.
  • Jelzők : Jelzők, amelyek különböző funkciókat vagy funkciókat képviselnek. A 0x80000 a „kiterjedések” zászló (erről bővebben alább).
  • Generálás : A hálózati fájlrendszer (NFS) ezt akkor használja, ha valaki hálózati kapcsolaton keresztül fér hozzá a távoli fájlrendszerekhez, mintha a helyi gépre lettek volna csatlakoztatva. Az inode és generációs számokat a fájlkezelés egyik formájaként használják.
  • Verzió : Az inode verzió.
  • Felhasználó : A fájl tulajdonosa.
  • Csoport : A fájl csoporttulajdonosa.
  • Projekt : Mindig nullának kell lennie.
  • Méret : A fájl mérete.
  • File ACL : A fájlelérés-vezérlési lista. Ezeket úgy alakítottuk ki, hogy ellenőrzött hozzáférést adhassanak olyan embereknek, akik nem tartoznak a tulajdonosok csoportjába.
  • Linkek : A fájlhoz vezető kemény linkek száma.
  • Blokkszám : A fájlhoz rendelt merevlemez-terület mennyisége, 512 bájtos darabokban megadva. A fájlunknak nyolcat osztottak ki, ami 4096 bájt. Tehát a 98 bájtos fájlunk egyetlen 4096 bájtos lemezblokkban helyezkedik el.
  • Töredék : Ez a fájl nem töredezett. (Ez egy elavult zászló.)
  • Ctime : A fájl létrehozásának időpontja.
  • Időpont : A fájl utolsó elérésének időpontja.
  • Mtime : A fájl utolsó módosításának időpontja.
  • Crtime : A fájl létrehozásának időpontja.
  • Extra inode mezők mérete : Az ext4 fájlrendszer lehetővé tette egy nagyobb lemezen lévő inode kiosztását formátum idején. Ez az érték az inode által használt extra bájtok száma. Ez az extra hely felhasználható az új kernek jövőbeli követelményeinek kielégítésére vagy a kiterjesztett attribútumok tárolására is.
  • Inode ellenőrző összeg : Az inode ellenőrző összege, amely lehetővé teszi az inode sérült felismerését.
  • Terjedelmek : Ha kiterjesztéseket használnak (az ext4-en alapértelmezés szerint ezek), akkor a fájlok lemezblokk-használatára vonatkozó metaadatoknak két számuk van, amelyek a töredezett fájl egyes részeinek kezdő és befejező mondatait jelzik. Ez hatékonyabb, mint a fájl minden részében elfoglalt minden lemezblokk tárolása. Van egy mértékünk, mert a kis fájlunk egy lemezblokkban ül ebben a blokkeltolásban.

Hol van a fájlnév?

Most rengeteg információval rendelkezünk a fájlról, de mint észrevehette, nem kaptuk meg a fájl nevét. Itt jön létre a könyvtárstruktúra. Linuxban, csakúgy, mint egy fájlban, a könyvtárban is van inode. A fájladatokat tartalmazó lemezblokkokra való hivatkozás helyett egy könyvtár inode a könyvtárstruktúrákat tartalmazó lemezblokkokra mutat.

Az inode-hoz képest a könyvtárstruktúra korlátozott mennyiségű információt tartalmaz egy fájlról. Csak a fájl inode számát, nevét és a név hosszát tartalmazza.

Az inode és a könyvtárstruktúra mindent tartalmaz, amit tudnia kell egy fájlról vagy könyvtárról (vagy egy alkalmazásról). A könyvtárstruktúra egy könyvtárlemez-blokkban található, tehát tudjuk, hogy a fájl melyik könyvtárban található. A könyvtárstruktúra megadja a fájl nevét és az inode számát. Az inode minden mást elmond nekünk a fájlról, ideértve az időbélyegeket, az engedélyeket és a fájladatok helyét a fájlrendszerben.

Directory Inodes

A könyvtár inode számát ugyanolyan egyszerűen láthatja, mint a fájloknál.

A következő példában ls a -l(hosszú formátum), -i(inode) és -d(könyvtár) opciókat használjuk, és megnézzük a workkönyvtárat:

ls -lid munka /

Mivel a -d(könyvtár) opciót használtuk, a  lsjelentések magáról a könyvtárról szólnak, nem pedig annak tartalmáról. A könyvtár inode 1443016.

Ennek megismétléséhez a homekönyvtárhoz írja be a következőket:

ls -lid ~

A homekönyvtár inode 1447510, a workkönyvtár pedig a saját könyvtárban található. Most nézzük meg a workkönyvtár tartalmát . A -d(könyvtár) opció helyett  az -a(összes) opciót fogjuk használni . Ez megmutatja azokat a könyvtárbejegyzéseket, amelyek általában rejtettek.

A következőket írjuk be:

ls -lia munka /

Mivel az -a(összes) opciót használtuk, az egy- (.) És a kétpontos (..) bejegyzések jelennek meg. Ezek a bejegyzések a könyvtárat (egypontos) és a szülőkönyvtárát (kettőspontot) képviselik.

Ha megnézi az egypontos bejegyzés inode számát, akkor az 1443016 - ugyanaz az inode szám, amelyet akkor kaptunk, amikor felfedeztük a workkönyvtár inode számát . Ezenkívül a kétpontos bejegyzés inode száma megegyezik a homekönyvtár inode számával .

Ezért használhatja a cd ..parancsot egy szinttel feljebb a könyvtárfában. Hasonlóképpen, amikor egy alkalmazás vagy szkript nevét megelőzi   ./, akkor közölje a héjjal, hogy honnan indítsa el az alkalmazást vagy a szkriptet.

Inodes és linkek

Amint kitértünk rá, három összetevőre van szükség ahhoz, hogy egy jól formázott és hozzáférhető fájl legyen a fájlrendszerben: a fájl, a könyvtárstruktúra és az inode. A fájl a merevlemezen tárolt adat, a könyvtárstruktúra tartalmazza a fájl nevét és inode számát, az inode pedig a fájl összes metaadatát.

A szimbolikus linkek fájlrendszeri bejegyzések, amelyek fájlokhoz hasonlítanak, de ezek valóban parancsikonok, amelyek egy meglévő fájlra vagy könyvtárra mutatnak. Lássuk, hogyan kezelik ezt, és hogyan használják a három elemet ennek elérésére.

Tegyük fel, hogy van egy könyvtárunk, amelyben két fájl található: az egyik egy szkript, a másik pedig egy alkalmazás, amint az alább látható.

Az ln paranccsal és a -s(szimbolikus) opcióval létrehozhatunk egy soft linket a szkriptfájlhoz, így:

ls -s my_script geek.sh

Létrehoztunk egy linket my_script.shnevezett geek.sh. Beírhatjuk az alábbiakat, és felhasználhatjuk  ls a két szkriptfájl megtekintésére:

ls -li * .sh

A bejegyzés geek.sh kék színnel jelenik meg. A jogosultsági jelzők első karaktere egy „l” jel a linkre, és  ->arra mutat my_script.sh. Mindez azt jelzi, hogy geek.shlink.

Ahogy valószínűleg elvárható, a két szkriptfájl eltérő inode számmal rendelkezik. Ami viszont meglepőbb, az a soft link,, geek.shnem rendelkezik ugyanazokkal a felhasználói engedélyekkel, mint az eredeti szkriptfájl. Valójában az engedélyek  geek.shsokkal liberálisabbak - minden felhasználó teljes jogosultsággal rendelkezik.

A geek.shcímtárstruktúra a link nevét és inódját tartalmazza. Amikor megpróbálja használni a linket, az inode-jára hivatkozik, csakúgy, mint egy normál fájlra. A link inode egy lemezblokkra mutat, de a fájl tartalmi adatok helyett a lemezblokk tartalmazza az eredeti fájl nevét. A fájlrendszer átirányítja az eredeti fájlra.

Töröljük az eredeti fájlt, és megnézzük, mi történik, ha az alábbiak beírásával megnézzük a tartalmát  geek.sh:

rm my_script.sh
macska geek.sh

A szimbolikus kapcsolat megszakad, és az átirányítás meghiúsul.

Most az alábbiakat írjuk be, hogy kemény linket hozzunk létre az alkalmazásfájlhoz:

Speciális alkalmazású geek-alkalmazás

Ennek a két fájlnak az inodes megtekintéséhez írja be a következőket:

ls -li

Mindkettő rendes fájlnak tűnik. Semmi nem geek-apputal arra, hogy ez egy link a lslistázás módjában geek.sh. Ráadásul  geek-app ugyanazokkal a felhasználói engedélyekkel rendelkezik, mint az eredeti fájl. Az azonban meglepő lehet, hogy mindkét alkalmazásnak azonos az inode száma: 1441797.

A címtár bejegyzése geek-apptartalmazza a „geek-app” nevet és egy inode számot, de megegyezik az eredeti fájl inode számával. Tehát két különböző nevű fájlrendszer-bejegyzésünk van, amelyek ugyanarra az inode-ra mutatnak. Valójában bármennyi elem utalhat ugyanarra az inode-ra.

Beírjuk a következőket, és a statprogram segítségével megnézzük a célfájlt:

stat special-app

Látjuk, hogy két hard link mutat erre a fájlra. Ezt az inode tárolja.

A következő példában töröljük az eredeti fájlt, és megpróbáljuk titkos, biztonságos jelszóval használni a linket:

rm speciális alkalmazás
./geek-app correcthorsebatteratteraple

Meglepő módon az alkalmazás a várakozásoknak megfelelően fut, de hogyan? Ez azért működik, mert egy fájl törlésekor az inode szabadon felhasználható. A címtárszerkezet nulla inode-számmal van megjelölve, és a lemezblokkok akkor rendelkezésre állnak egy másik fájl számára, amelyet ezen a helyen tárolhatnak.

Ha az inode-hoz tartozó hard linkek száma egynél nagyobb, akkor a hard linkek száma eggyel csökken, és a törölt fájl könyvtárstruktúrájának inode száma nulla. A merevlemez és az inode fájl tartalma továbbra is elérhető a meglévő merevlemez-linkek számára.

Beírjuk a következőket, és még egyszer használjuk a stat-t - ezúttal geek-app:

stat geek-app

Ezek a részletek ugyanarról az inode-ról (1441797) származnak, mint az előző statparancs. A linkek száma eggyel csökkent.

Mivel ezen az inódon egy kemény hivatkozás áll rendelkezésünkre, ha törölnénk,  geek-appaz valóban törölné a fájlt. A fájlrendszer felszabadítja az inode-ot, és a könyvtárstruktúrát nulla inóddal jelöli. Ezután egy új fájl felülírhatja a merevlemez adattárát.

KAPCSOLÓDÓ: Hogyan használjuk a stat parancsot Linuxon

Inode általános költségek

ügyes rendszer, de vannak rezsiköltségek. Egy fájl olvasásához a fájlrendszernek a következőket kell tennie:

  • Keresse meg a megfelelő könyvtárstruktúrát
  • Olvassa el az inode számát
  • Találja meg a megfelelő inode-t
  • Olvassa el az inode információkat
  • Kövesse az inode hivatkozásokat vagy a vonatkozó lemezblokkok kiterjedését
  • Olvassa el a fájl adatait

Még egy kicsit tovább kell ugrani, ha az adatok nem egybehangzóak.

Képzelje el azt a munkát, amelynek  ls elvégzéséhez sok fájl hosszú formátumú fájllistája szükséges. Nagyon sok oda-vissza van csak lsa kimenet létrehozásához szükséges információk megszerzéséhez.

Természetesen a fájlrendszerhez való hozzáférés felgyorsítása az oka annak, hogy a Linux megpróbálja a lehető legtöbb megelőző fájl-gyorsítótárat végrehajtani. Ez nagyban segít, de néha - mint minden fájlrendszer esetében - nyilvánvalóvá válhatnak a rezsiköltségek.

Most már tudni fogja, miért.