Linux-filsystemet er avhengig av inoder. Disse vitale delene av filsystemets indre funksjoner blir ofte misforstått. La oss se på nøyaktig hva de er, og hva de gjør.
Innholdsfortegnelse
Elementene til et filsystem
Per definisjon må et filsystem lagre filer, og de inneholder også kataloger. Filene er lagret i katalogene, og disse katalogene kan ha underkataloger. Noe, et sted, må registrere hvor alle filene er plassert i filsystemet, hva de heter, hvilke kontoer de tilhører, hvilke tillatelser de har og mye mer. Denne informasjonen kalles metadata fordi det er data som beskriver andre data.
I Linux ext4 filsystemet, den inode og katalogstrukturer arbeide sammen for å gi et underliggende rammeverk som lagrer alle metadataene for hver fil og katalog. De gjør metadataene tilgjengelige for alle som trenger det, enten det er kjernen, brukerapplikasjoner eller Linux-verktøy, som ls, stat og df.
Inoder og filsystemstørrelse
Selv om det er sant at det er et par strukturer, krever et filsystem mye mer enn det. Det er tusenvis og tusenvis av hver struktur. Hver fil og katalog krever en inode, og fordi hver fil er i en katalog, krever hver fil også en katalogstruktur. Katalogstrukturer kalles også katalogoppføringer, eller «dentries».
Hver inode har et inodenummer, som er unikt i et filsystem. Det samme inodenummeret kan vises i mer enn ett filsystem. Filsystem-ID og inodenummer kombineres imidlertid for å lage en unik identifikator, uavhengig av hvor mange filsystemer som er montert på Linux-systemet.
Husk at i Linux monterer du ikke en harddisk eller partisjon. Du monterer filsystemet som er på partisjonen, så det er lett å ha flere filsystemer uten å være klar over det. Hvis du har flere harddisker eller partisjoner på en enkelt stasjon, har du mer enn ett filsystem. De kan være av samme type – alle ext4, for eksempel – men de vil fortsatt være forskjellige filsystemer.
Alle inoder holdes i ett bord. Ved å bruke et inodenummer, beregner filsystemet enkelt forskyvningen inn i inodetabellen der den inoden er plassert. Du kan se hvorfor «i» i inode står for indeks.
Variabelen som inneholder inodenummeret er deklarert i kildekoden som et 32-bits langt heltall uten fortegn. Dette betyr at inodetallet er en heltallsverdi med en maksimal størrelse på 2^32, som beregnes til 4.294.967.295 – godt over 4 milliarder inoder.
Det er det teoretiske maksimum. I praksis bestemmes antall inoder i et ext4-filsystem når filsystemet opprettes med et standardforhold på én inode per 16 KB filsystemkapasitet. Katalogstrukturer opprettes i farten når filsystemet er i bruk, ettersom filer og kataloger opprettes i filsystemet.
Det er en kommando du kan bruke for å se hvor mange inoder som er i et filsystem på datamaskinen din. Alternativet -i (inoder) til df-kommandoen instruerer det til vise produksjonen i antall inoder.
Vi skal se på filsystemet på den første partisjonen på den første harddisken, så vi skriver inn følgende:
df -i /dev/sda1
Utgangen gir oss:
Filsystem: Filsystemet det rapporteres om.
Inoder: Totalt antall inoder i dette filsystemet.
IUsed: Antall inoder i bruk.
IFree: Antall gjenværende inoder tilgjengelig for bruk.
IUse%: Prosentandelen av brukte inoder.
Montert på: Monteringspunktet for dette filsystemet.
Vi har brukt 10 prosent av inodene i dette filsystemet. Filer lagres på harddisken i diskblokker. Hver inode peker på diskblokkene som lagrer innholdet i filen de representerer. Hvis du har millioner av små filer, kan du gå tom for inoder før du går tom for plass på harddisken. Det er imidlertid et veldig vanskelig problem å støte på.
Tidligere hadde noen e-postservere som lagret e-postmeldinger som diskrete filer (som raskt førte til store samlinger av små filer) dette problemet. Når disse applikasjonene endret bakenden til databaser, løste dette imidlertid problemet. Det gjennomsnittlige hjemmesystemet vil ikke gå tom for inoder, noe som er like greit fordi, med ext4-filsystemet, kan du ikke legge til flere inoder uten å installere filsystemet på nytt.
For å se størrelsen på diskblokkene på filsystemetkan du bruke blockdev-kommandoen med alternativet –getbsz (hent blokkstørrelse):
sudo blockdev --getbsz /dev/sda
Blokkstørrelsen er 4096 byte.
La oss bruke alternativet -B (blokkstørrelse) for å spesifisere en blokkstørrelse på 4096 byte og sjekke vanlig diskbruk:
df -B 4096 /dev/sda1
Denne utgangen viser oss:
Filsystem: Filsystemet som vi rapporterer om.
4K-blokker: Det totale antallet 4 KB-blokker i dette filsystemet.
Brukt: Hvor mange 4K-blokker er i bruk.
Tilgjengelig: Antall gjenværende blokker på 4 KB som er tilgjengelige for bruk.
Bruk%: Prosentandelen av blokker på 4 KB som har blitt brukt.
Montert på: Monteringspunktet for dette filsystemet.
I vårt eksempel har fillagring (og lagring av inodene og katalogstrukturene) brukt 28 prosent av plassen på dette filsystemet, til en pris av 10 prosent av inodene, så vi er i god form.
Inode Metadata
For å se inodenummeret til en fil, kan vi bruke ls med alternativet -i (inode):
ls -i geek.txt
Inodenummeret for denne filen er 1441801, så denne inoden inneholder metadataene for denne filen og, tradisjonelt, pekerne til diskblokkene der filen ligger på harddisken. Hvis filen er fragmentert, veldig stor eller begge deler, kan noen av blokkene inoden peker på inneholde ytterligere peker til andre diskblokker. Og noen av de andre diskblokkene kan også holde pekere til et annet sett med diskblokker. Dette overvinner problemet med at inoden har en fast størrelse og kan holde et begrenset antall pekere til diskblokker.
Denne metoden ble erstattet av en ny ordning som bruker «omfang.» Disse registrerer start- og sluttblokken til hvert sett med sammenhengende blokker som brukes til å lagre filen. Hvis filen er ufragmentert, trenger du bare å lagre den første blokken og fillengden. Hvis filen er fragmentert, må du lagre den første og siste blokken i hver del av filen. Denne metoden er (åpenbart) mer effektiv.
Hvis du vil se om filsystemet ditt bruker diskblokkpekere eller -utstrekninger, kan du se inne i en inode. For å gjøre det, bruker vi kommandoen debugfs med alternativet -R (forespørsel), og gi den inoden til filen av interesse. Dette ber debugfs bruke sin interne «stat»-kommando for å vise innholdet i inoden. Fordi inodenumre bare er unike i et filsystem, må vi også fortelle debugfs filsystemet som inoden ligger på.
Slik vil denne eksempelkommandoen se ut:
sudo debugfs -R "stat " /dev/sda1
” /dev/sda1″ kommando i et terminalvindu.» width=”646″ height=”57″ onload=”pagespeed.lazyLoadImages.loadIfVisibleAndMaybeBeacon(this);” onerror=”this.onerror=null;pagespeed.lazyLoadImages.loadIfVisibleAndMaybeBeacon(this);”>
Som vist nedenfor trekker debugfs-kommandoen ut informasjonen fra inoden og presenterer den for oss på mindre:
Vi får vist følgende informasjon:
Inode: Nummeret på inoden vi ser på.
Type: Dette er en vanlig fil, ikke en katalog eller symbolsk lenke.
Modus: Filtillatelsene i oktal.
Flagg: Indikatorer som representerer ulike egenskaper eller funksjonalitet. 0x80000 er «omfang»-flagget (mer om dette nedenfor).
Generasjon: A Nettverksfilsystem (NFS) bruker dette når noen får tilgang til eksterne filsystemer over en nettverkstilkobling som om de var montert på den lokale maskinen. Inode- og generasjonsnumrene brukes som en form for filhåndtak.
Versjon: Inode-versjonen.
Bruker: Eieren av filen.
Gruppe: Gruppeeieren av filen.
Prosjekt: Skal alltid være null.
Størrelse: Størrelsen på filen.
Fil ACL: Listen for filtilgangskontroll. Disse ble designet for å tillate deg å gi kontrollert tilgang til personer som ikke er i eiergruppen.
Lenker: Antall harde lenker til filen.
Blockcount: Mengden harddiskplass som er tildelt denne filen, gitt i 512-byte biter. Filen vår har blitt tildelt åtte av disse, som er 4096 byte. Så vår 98-byte fil ligger innenfor en enkelt 4096-byte diskblokk.
Fragment: Denne filen er ikke fragmentert. (Dette er et utdatert flagg.)
Ctime: Tidspunktet da filen ble opprettet.
Atime: Tidspunktet da denne filen sist ble åpnet.
Mtime: Tidspunktet da denne filen sist ble endret.
Crtime: Tidspunktet da filen ble opprettet.
Størrelse på ekstra inodefelt: Ext4-filsystemet introduserte muligheten til å tildele en større inode på disken ved formateringstidspunkt. Denne verdien er antall ekstra byte inoden bruker. Denne ekstra plassen kan også brukes til å imøtekomme fremtidige krav til nye kjerner eller til å lagre utvidede attributter.
Inode sjekksum: En sjekksum for denne inoden, som gjør det mulig å oppdage om inoden er ødelagt.
Omfang: Hvis utstrekninger brukes (på ext4 er de det som standard), har metadataene angående diskblokkbruken av filer to tall som indikerer start- og sluttblokkene for hver del av en fragmentert fil. Dette er mer effektivt enn å lagre hver diskblokk som tas opp av hver del av en fil. Vi har ett omfang fordi vår lille fil sitter i en diskblokk ved denne blokkforskyvningen.
Hvor er filnavnet?
Vi har nå mye informasjon om filen, men som du kanskje har lagt merke til, fikk vi ikke filnavnet. Det er her katalogstrukturen kommer inn i bildet. I Linux, akkurat som en fil, har en katalog en inode. I stedet for å peke på diskblokker som inneholder fildata, peker en kataloginode til diskblokker som inneholder katalogstrukturer.
Sammenlignet med en inode inneholder en katalogstruktur en begrenset mengde informasjon om en fil. Den inneholder bare filens inodenummer, navn og lengden på navnet.
Inoden og katalogstrukturen inneholder alt du (eller et program) trenger å vite om en fil eller katalog. Katalogstrukturen er i en katalogdiskblokk, så vi vet hvilken katalog filen er i. Katalogstrukturen gir oss filnavnet og inodenummeret. Inoden forteller oss alt annet om filen, inkludert tidsstempler, tillatelser og hvor vi finner fildataene i filsystemet.
Directory Inoder
Du kan se inodenummeret til en katalog like enkelt som du kan se dem for filer.
I det følgende eksempelet bruker vi ls med alternativene -l (langt format), -i (inode) og -d (katalog), og ser på arbeidskatalogen:
ls -lid work/
Fordi vi brukte alternativet -d (katalog), rapporterer ls om selve katalogen, ikke innholdet. Inoden for denne katalogen er 1443016.
For å gjenta det for hjemmekatalogen, skriver vi følgende:
ls -lid ~
Inoden for hjemmekatalogen er 1447510, og arbeidskatalogen er i hjemmekatalogen. La oss nå se på innholdet i arbeidskatalogen. I stedet for alternativet -d (katalog), bruker vi alternativet -a (alle). Dette vil vise oss katalogoppføringene som vanligvis er skjult.
Vi skriver følgende:
ls -lia work/
Fordi vi brukte alternativet -a (alle), vises enkelt- (.) og doble prikker (..). Disse oppføringene representerer selve katalogen (enkelt prikk), og dens overordnede katalog (dobbel prikk.)
Hvis du ser på inodenummeret for enkeltpunktoppføringen, ser du at det er 1443016 – det samme inodenummeret vi fikk da vi oppdaget inodenummeret for arbeidskatalogen. Dessuten er inodenummeret for dobbeltpunktoppføringen det samme som inodenummeret for hjemmekatalogen.
Det er derfor du kan bruke cd ..-kommandoen for å flytte opp et nivå i katalogtreet. På samme måte, når du går foran et program- eller skriptnavn med ./, lar du skallet vite hvorfra programmet eller skriptet skal startes.
Inoder og lenker
Som vi har dekket, kreves det tre komponenter for å ha en godt utformet og tilgjengelig fil i filsystemet: filen, katalogstrukturen og inoden. Filen er dataene som er lagret på harddisken, katalogstrukturen inneholder navnet på filen og dens inodenummer, og inoden inneholder alle metadataene for filen.
Symbolske lenker er filsystemoppføringer som ser ut som filer, men de er egentlig snarveier som peker til en eksisterende fil eller katalog. La oss se hvordan de klarer dette, og hvordan de tre elementene brukes for å oppnå dette.
La oss si at vi har en katalog med to filer i den: den ene er et skript, og den andre er en applikasjon, som vist nedenfor.
Vi kan bruke ln-kommandoen og -s (symbolsk) alternativet for å lage en myk lenke til skriptfilen, slik:
ls -s my_script geek.sh
Vi har laget en lenke til my_script.sh kalt geek.sh. Vi kan skrive følgende og bruke ls for å se på de to skriptfilene:
ls -li *.sh
Oppføringen for geek.sh vises i blått. Det første tegnet i tillatelsesflaggene er en «l» for lenke, og -> peker til my_script.sh . Alt dette indikerer at geek.sh er en lenke.
Som du sannsynligvis forventer, har de to skriptfilene forskjellige inodenumre. Det som imidlertid kan være mer overraskende, er at den myke lenken, geek.sh, ikke har de samme brukertillatelsene som den originale skriptfilen. Faktisk er tillatelsene for geek.sh mye mer liberale – alle brukere har fulle tillatelser.
Katalogstrukturen for geek.sh inneholder navnet på lenken og dens inode. Når du prøver å bruke lenken, refereres det til inoden, akkurat som en vanlig fil. Koblingsinoden vil peke til en diskblokk, men i stedet for å inneholde filinnholdsdata, inneholder diskblokken navnet på den originale filen. Filsystemet omdirigerer til den opprinnelige filen.
Vi sletter den originale filen, og ser hva som skjer når vi skriver følgende for å se innholdet i geek.sh:
rm my_script.sh
cat geek.sh
Den symbolske koblingen er brutt, og omdirigeringen mislykkes.
Vi skriver nå følgende for å lage en hard lenke til applikasjonsfilen:
ln special-app geek-app
For å se på inodene for disse to filene, skriver vi følgende:
ls -li
Begge ser ut som vanlige filer. Ingenting om geek-app indikerer at det er en lenke slik ls-oppføringen for geek.sh gjorde. I tillegg har geek-app de samme brukertillatelsene som den originale filen. Det som imidlertid kan være overraskende er at begge applikasjonene har samme inodenummer: 1441797.
Katalogoppføringen for geek-app inneholder navnet «geek-app» og et inodenummer, men det er det samme som inodenummeret til den originale filen. Så vi har to filsystemoppføringer med forskjellige navn som begge peker til samme inode. Faktisk kan et hvilket som helst antall elementer peke til den samme inoden.
Vi skriver inn følgende og bruker stat-programmet for å se på målfilen:
stat special-app
Vi ser at to harde lenker peker til denne filen. Dette lagres i inoden.
I følgende eksempel sletter vi den opprinnelige filen og prøver å bruke koblingen med en hemmelig, sikkert passord:
rm special-app
./geek-app correcthorsebatterystaple
Overraskende nok kjører applikasjonen som forventet, men hvordan? Det fungerer fordi, når du sletter en fil, er inoden gratis å gjenbrukes. Katalogstrukturen er merket som å ha et inodenummer på null, og diskblokkene er da tilgjengelige for en annen fil som kan lagres på den plassen.
Hvis antallet harde lenker til inoden er større enn én, reduseres imidlertid antallet harde lenker med én, og inodenummeret til katalogstrukturen til den slettede filen settes til null. Filinnholdet på harddisken og inoden er fortsatt tilgjengelig for de eksisterende harddiskkoblingene.
Vi skriver inn følgende og bruker stat en gang til – denne gangen på geek-app:
stat geek-app
Disse detaljene er hentet fra den samme inoden (1441797) som den forrige stat-kommandoen. Linkantallet ble redusert med én.
Fordi vi har en hard lenke til denne inoden, hvis vi sletter geek-appen, ville den virkelig slette filen. Filsystemet vil frigjøre inoden og merke katalogstrukturen med en inode på null. En ny fil kan da overskrive datalagringen på harddisken.
Inode Overhead
det er et pent system, men det er overhead. For å lese en fil, må filsystemet gjøre alle følgende:
Finn riktig katalogstruktur
Les inodenummeret
Finn den rette inoden
Les inodeinformasjonen
Følg enten inode-lenkene eller utstrekningen til de relevante diskblokkene
Les fildataene
Litt mer hopping rundt er nødvendig hvis dataene ikke er sammenhengende.
Tenk deg arbeidet som må gjøres for at ls skal utføre en langformatfilliste over mange filer. Det er mye frem og tilbake bare for å få informasjonen den trenger for å generere utdata.
Å øke hastigheten på filsystemtilgang er selvfølgelig grunnen til at Linux prøver å gjøre så mye forebyggende filbufring som mulig. Dette hjelper veldig, men noen ganger – som med ethvert filsystem – kan kostnadene bli tydelige.
Nå vet du hvorfor.