Filsystemet för Linux bygger på inoder. Dessa viktiga delar av filsystemet inre arbetet är ofta missförstått. Låt oss titta på precis vad de är och vad de gör.
De Delar av ett filsystem
Per definition, ett filsystem för att lagra filer, och de innehåller också kataloger. Filerna lagras i kataloger, och dessa kataloger kan ha underkataloger. Något, någonstans, har att skiva där alla filer ligger i filsystemet, vad de kallas, vilka konton de tillhör, vilka behörigheter de har, och mycket mer. Denna information kallas metadata, eftersom det är data som beskriver andra data.
I Linux-filsystemet ext4, inode och strukturer katalog arbetar tillsammans för att ge en grund ram som lagrar alla metadata för varje fil och katalog. De gör metadata är tillgänglig för alla som behöver det, oavsett om det är kärnan, applikationer som användaren eller Linux-verktyg, som t ex ls, stat, och df.
Inoder och filsystem Storlek
Medan det är sant att det är ett par av strukturer, ett filsystem kräver många fler än så. Det finns tusentals och åter tusentals av varje struktur. Varje fil och katalog kräver en inode, och eftersom varje fil i en katalog, varje fil kräver också en katalogstruktur. Katalog strukturer kallas också katalogposter, eller “dentries.”
Varje inode har en inode nummer, som är unikt inom ett filsystem. Samma inode nummer kan visas i mer än en fil systemet. Men file system-ID och inode nummer kombineras för att skapa en unik identifierare, oavsett hur många filsystem som är monterade på ditt Linux-system.
Kom ihåg, i Linux, kan du inte montera en hårddisk eller partition. Du montera filsystem på partitionen, så det är lätt att ha flera filsystem utan att inse det. Om du har flera hårddiskar eller partitioner på en enda enhet, om du har mer än en fil systemet. De kan vara av samma typ—alla ext4, till exempel—men de kommer ändå att vara tydlig filsystem.
Alla inoder hålls i en tabell. Med hjälp av en inode nummer, filsystemet lätt beräknar förskjutningen i inode bord som inode är beläget. Kan du se varför “jag” i inode står för index.
Den variabel som innehåller de inode nummer är deklarerade i källkoden som en 32-bitars, unsigned long integer. Detta innebär inode nummer ett heltal med en storlek på högst 2^32, som beräknar ut till 4294967295—väl över 4 miljarder inoder.
Det är den teoretiska maximala. I praktiken antalet inoder på ett ext4-filsystem bestäms när filen är skapad på ett grundvärde som gäller för en inode per 16 KB av filen systemets kapacitet. Katalog strukturer skapas i farten när filen är i användning, som filer och kataloger skapas inom filsystemet.
Det finns ett kommando som du kan använda för att se hur många inoder är i ett filsystem på din dator. -Jag (inoder) – flaggan med kommandot df uppdrar åt den för att visa sin produktion i antal inoder.
Vi kommer att titta på filsystemet på den första partitionen på den första hårddisken, så vi skriver följande:
df-i /dev/sda1
Produktionen ger oss:
- Filsystem: file system rapporteras på.
- Inoder: Det totala antalet inoder i detta filsystem.
- IUsed: antalet inoder i bruk.
- IFree: antalet återstående inoder tillgängliga för användning.
- IUse%): andelen som används inoder.
- Monterad på: monteringspunkt för detta filsystem.
Vi har använt 10 procent av inoder i detta filsystem. Filer som är lagrade på hårddisken i disken block. Varje inode poäng till disken block för att lagra innehållet i den fil som de representerar. Om du har miljontals små filer, du kan springa ut inoder innan du får slut på utrymme på hårddisken. Men det är ett mycket svårt problem att köra på.
I det förflutna, vissa e-postservrar som lagras e-postmeddelanden som separata filer (som snabbt ledde till att stora samlingar av små filer) hade denna fråga. När dessa program ändrat sina baksidor till databaser, detta löste problemet, dock. Den genomsnittliga hem att systemet inte kommer att köras av inoder, som är lika bra, för i och med filsystemet ext4, du kan inte lägga till mer inoder utan att installera filsystemet.
För att se storleken på disken block i filsystemet kan du använda blockdev kommandot med –getbsz (får block size) alternativ:
sudo blockdev –getbsz /dev/sda
Blockstorlek är 4096 byte.
Låt oss använda den -B (block size) alternativet för att ange ett block storlek 4096 byte och kontrollera regelbundet diskanvändning:
df -B 4096 /dev/sda1
Denna utgång visar oss:
- Filsystem: file system som vi är rapporter.
- 4K-block: totalt antal 4 KB block i filsystemet.
- Används: Hur många 4K block är i användning.
- Tillgänglig: antalet återstående 4 KB block som är tillgängliga för användning.
- Använd%): andelen av 4 KB block som har använts.
- Monterad på: monteringspunkt för detta filsystem.
I vårt exempel, fil lagring (och lagring av inoder och strukturer katalog) har används för 28 procent av utrymmet på det här filsystemet, till priset av 10 procent av inoder, så vi är i god form.
Inode Metadata
För att se inode nummer av en fil, kan vi använda ls med -jag (inode) alternativ:
ls -jag geek.txt
Inode antal för denna fil är 1441801, så detta inode har metadata för denna fil och traditionellt pekare till disk block där filen finns på hårddisken. Om fil är fragmenterad, mycket stora, eller både och, en del av blocken inode poäng för att kanske hålla ytterligare en pekare till annan disk block. Och några av de andra skiva block kan också hålla pekare till en annan uppsättning av diskblock. Detta överbryggar problemet med inode att ha en fast storlek och kan hålla ett begränsat antal referenser till disk block.
Som metod har ersatts av ett nytt system som använder sig av “grad.” Dessa spela in början och slutet av block av varje uppsättning sammanhängande block som används för att lagra filen. Om filen är enhetligt, du har bara att lagra det första blocket och filens längd. Om fil är fragmenterad, du har för att lagra den första och sista block av varje del av filen. Denna metod är (uppenbarligen) mer effektiv.
Om du vill se om din filsystemet använder disk block-pekare eller omfattning, du kan titta in för en inode. Att göra så, ska vi använda debugfs kommando-R (begäran) alternativ, och passera den inode av filen som är av intresse. Detta frågar debugfs att använda sina interna “stat” – kommandot för att visa innehållet i inode. Eftersom inode nummer är bara unik i ett filsystem, måste vi också tala debugfs filsystemet som inode är bosatt.
Här är vad detta exempel på kommando skulle se ut:
sudo debugfs -R “stat <1441801>” /dev/sda1
Som framgår nedan, debugfs kommandot extrahera information från inode och presenterar det för oss i mindre:
Vi visas följande information:
- Inode: antalet inode vi tittar på.
- Typ: Detta är en vanlig fil, inte en katalog eller symbolisk länk.
- Läge: behörigheterna i oktalt.
- Flaggor: Indikatorer som representerar olika egenskaper eller funktioner. Den 0x80000 är “extents” flagga (mer om detta nedan).
- Generation: En för Network File System (NFS) använder denna när någon ansluter till remote file system via en nätverksanslutning som om de var monterade på den lokala maskinen. Inode och generation-nummer används som en form av fil handtag.
- Version: inode version.
- Användare: ägaren av filen.
- Grupp: Den grupp som ägare av filen.
- Projekt: Ska alltid vara noll.
- Storlek: storleken på filen.
- Fil ACL: file access control list. Dessa var utformade för att tillåta dig att ge kontrollerad tillgång till människor som inte är i gruppen ägare.
- Länkar: antal hårda länkar till filen.
- Blockcount: mängden hårddiskutrymme som avsatts till denna fil, med tanke på 512 byte bitar. Våra filen har tilldelats åtta av dessa, vilket är 4 096 byte. Så, våra 98 byte fil sitter i en enda på 4 096 byte disk block.
- Fragment: Denna fil är inte splittrad. (Detta är en föråldrad flagga.)
- Ctime: Den tid när filen skapades.
- Tid: Den tid då filen senast tillgängliga.
- Mtime: Den tidpunkt då filen ändrades senast.
- Crtime: Den tid när filen skapades.
- Storlek extra inode fält: ext4 file system införs möjligheten att fördela en större disk inode på format tid. Detta värde är antalet extra byte inode är med. Detta extra utrymme kan också användas för att tillgodose framtida behov av nya kärnor eller för att lagra utökade attribut.
- Inode kontrollsumma: En kontrollsumma för detta inode, vilket gör det möjligt att upptäcka om inode är skadad.
- Omfattning: Om grad används (på ext4, de är, som standard), metadata om disken block användning av filer som har två siffror för att ange början och slutet av block av varje del av en fragmenterad fil. Detta är effektivare än att förvara varje skiva block tas upp av varje del av en fil. Vi har en del på att våra små filer som ligger i en disk block på detta block offset.
Där är filnamn?
Vi har nu en hel del information om filen, men, som ni kanske har märkt, att vi inte få filnamnet. Det är där directory-strukturen kommer in. I Linux, precis som en fil, en katalog har en inode. Snarare än att peka på disk block som innehåller filen data, men en katalog inode poäng till disk block som innehåller katalogen strukturer.
Jämfört med en inode, en katalog struktur innehåller en begränsad mängd information om en fil. Det har bara filens inode nummer, namn, och längden på namnet.
Inode och katalogstrukturen innehåller allt du (eller ett program) behöver att veta om en fil eller katalog. Katalogstrukturen är i en katalog disk block, så vi vet att den katalog som filen ligger i. Katalogstrukturen ger oss filnamnet och inode nummer. Inode berättar allt om filen, inklusive tidsstämplar, behörigheter och om att hitta den file data i filsystemet.
Katalog Inoder
Du kan se inode nummer av en katalog lika lätt som du kan se dem för filer.
I följande exempel kommer vi att använda ls med flaggan-l (long-format), -i (inode), och -d (katalog) alternativ, och titta på det arbete katalogen:
ls -lock-arbete/
Eftersom vi använde -d (katalog) alternativ, ls rapporter om katalogen själv, inte för dess innehåll. Inode för denna katalog är 1443016.
Att upprepa att för hemkatalogen, vi typ följande:
ls -lock ~
Inode för hemkatalogen är 1447510, och arbetet katalog i hemkatalogen. Nu, låt oss titta på innehållet i arbetet katalog. I stället för-d (katalog) alternativ, som vi ska använda den -alla alternativ. Detta kommer att visa oss de katalogposter som vanligtvis är dolda.
Vi skriver följande:
ls -lia-arbete/
Eftersom vi använde -en (alla) alternativ, det enda- (.) och dubbel-dot (..) poster visas. Dessa poster utgör katalogen (single-punkt), och dess överordnade katalogen (dubbel-prick.)
Om du tittar på inode nummer för enkel-prick inlägg, att det’s1443016—samma inode nummer som vi fick när vi upptäckte inode nummer för arbete katalog. Även inode nummer för dubbel-prick inlägg är samma som inode nummer för hemkatalogen.
Det är därför du kan använda kommandot cd .. för att gå en nivå uppåt i katalogen träd. Likaså när du föregår en ansökan eller ett skript namn med ./, du låter skalet vet var jag ska starta programmet eller skriptet.
Inoder och Länkar
Som vi har täckt tre komponenter krävs det att du har en välformad och tillgänglig filen i systemet: den fil, katalog struktur, och inode. Filen är data som lagras på hårddisken, i den katalog struktur innehåller namnet på filen och dess inode nummer, och inode innehåller all metadata till filen.
Symboliska länkar poster i filsystemet som ser ut som filer, men de är verkligen genvägar att peka på en existerande fil eller katalog. Låt oss se hur de hanterar detta, och hur de tre elementen som används för att uppnå detta.
Låt oss säga att vi har fått en katalog med två filer i: det ena är ett manus, och den andra är ett program, som visas nedan.
Vi kan använda ln kommandot och -s (symbolisk) alternativet för att skapa en mjuk länk till skript-fil, så här:
ls -s my_script geek.sh
Vi har skapat en länk till my_script.sh kallas geek.sh. Vi kan skriva följande och använda ls för att titta på de två skript-filer:
ls -li *.sh
Posten för geek.sh visas i blått. Det första tecknet av behörigheter flaggor är ett “l” för länken, och -> poäng för att my_script.sh . Allt detta tyder på att geek.sh är en länk.
Som du nog räkna med, de två skriptfiler har olika inode nummer. Vad kan vara mer överraskande är dock den mjuka länken, geek.sh och inte har samma användarbehörigheter som den ursprungliga script-fil. I själva verket behörigheter för geek.sh är mycket mer liberal—alla användare som har fullständig behörighet.
Katalogstrukturen för geek.sh innehåller namnet på länken och dess inode. När du försöker använda länken, dess inode refereras, precis som en vanlig fil. Länken inoden kommer att peka på en disk block, men i stället för att som innehåller filen innehåll, data, disk block innehåller namn på den ursprungliga filen. Filsystemet omdirigeringar till den ursprungliga filen.
Vi ska ta bort den ursprungliga filen, och se vad som händer när vi skriver följande om du vill visa innehållet i geek.sh:
rm my_script.sh
katt geek.sh
Den symboliska länken är bruten, och omdirigera misslyckas.
Vi skriv nu följande för att skapa en hård länk till ansökan:
ln special-app geek-app
Att titta på inoder för dessa två filer, vi typ följande:
ls -li
Båda ser ut som vanliga filer. Ingenting om geek-app visar att det är en länk på det sätt ls notering för geek.sh gjorde. Plus, geek-appen har samma användarbehörigheter som den ursprungliga filen. Men vad som kan vara förvånande är båda programmen har samma inode nummer: 1441797.
Den katalogpost för geek-app innehåller namnet “geek-app” och en inode nummer, men det är samma sak som inode nummer av den ursprungliga filen. Så, vi har två poster i filsystemet med olika namn som bägge pekar på samma inode. I själva verket, valfritt antal poster som kan peka till samma inode.
Vi kommer att skriva följande och använda den stat program för att titta på målfilen:
stat special-app
Vi ser att två hårda länkar pekar till den här filen. Detta lagras i inode.
I följande exempel kommer vi att ta bort den ursprungliga filen och prova att använda den länk med en hemlighet, säkert lösenord:
rm special-app
./geek-app correcthorsebatterystaple
Överraskande, programmet körs som förväntat, men hur? Det fungerar eftersom när du tar bort en fil, inode är gratis att återanvändas. Katalogstrukturen är markerade med en inode nummer noll, och disken block är sedan tillgängliga för en annan fil lagras i det utrymmet.
Om antal hårda länkar till inode är större än ett, men det är svårt länk räkna minskas med en, och inode nummer av katalogstrukturen för den raderade filen är inställd på noll. Innehållet i filen på hårddisken och inode fortfarande är tillgänglig för befintliga hårda länkar.
Vi kommer att skriva följande och använda stat än en gång—denna gång på geek-app:
stat geek-app
Dessa uppgifter är hämtade från samma inode (1441797) som föregående stat kommando. Länken räkna minskat med en.
Eftersom vi är nere på en hård länk till denna inode, om vi tar bort nörd-app, det skulle verkligen ta bort filen. Filsystemet kommer gratis upp inode och markera den katalog struktur med en inode noll. En ny fil kan sedan skriva över den data som lagras på din hårddisk.
RELATERAT: Hur man Använder den stat Kommandot i Linux
Inode Omkostnader
det är en snygg system, men det finns omkostnader. För att läsa en fil som systemet har att göra följande:
- Hitta rätt katalogstruktur
- Läs inode nummer
- Hitta rätt inode
- Läs inode information
- Följ antingen inode länkar eller omfattning att relevanta disk block
- Läs filen data
Lite fler hoppar runt är nödvändigt om data är icke-angränsande.
Tänk dig att det arbete som måste göras för ls att utföra en lång format notering av många filer. Det är mycket fram och tillbaka bara för ls för att få den information den behöver för att generera sin produktion.
Naturligtvis snabbar upp filsystemet tillgång till varför Linux försöker att göra så mycket föregripande fil caching som möjligt. Detta hjälper mycket, men ibland—som med alla filsystem—omkostnader kan bli uppenbara.
Nu vet du varför.
LÄS NÄSTA
- “Hur man Lägger till Egna Ringsignaler för iPhone från macOS Catalina
- “Den Ultimata Guiden till Rengöring av Icky AirPods
- “Microsoft Testar Annonser i WordPad i Windows 10
- “Vad Är ett Internet-Troll? (och Hur man ska Hantera Troll)
- “Vad Är en GaN-Laddare, och Varför Ska Du Ha En?