Filsystemer. Martin Gilje Jaatun. 30. april 2007

Filsystemer Martin Gilje Jaatun 30. april 2007 Sammendrag Dette dokumentet er et forsøk på å formidle noen velmenende formuleringer om filsystemer og deres implementasjon, dvs. kapittel 11 og 12 i [SGG02]. Dokumentet er for det meste basert på [SGG01], som er foiler utarbeidet (på vegne?) av forfatterene av [SGG02]. Den observante leser vil ha registrert at dokumentet er skrevet på norsk, og norske uttrykk er derfor forsøkt brukt gjennomgående. Imidlertid er etablerte engelske forkortelser beholdt. Innhold 1 Fil-konseptet - hva er en fil? 3 1.1 Filstruktur................................ 3 1.2 Fil-attributter............................... 3 1.3 Filoperasjoner............................... 4 1.4 Aksessmetoder.............................. 4 2 Katalogstruktur 6 2.1 Montering av filsystemer......................... 10 2.2 Fildeling.................................. 10 3 Implementasjon av filsystemer 12 3.1 Filsystem-strukturer i minnet...................... 13 3.2 Virtuelle filsystemer........................... 15 3.3 Implementasjon av en katalog...................... 15 4 Tildelingsmetoder 16 4.1 Sammenhengende tildeling........................ 16 4.2 Lenket tildeling.............................. 16 4.3 Indeksert tildeling............................ 19 1

5 Håndtering av ledig plass 20 5.1 Ledig-liste................................. 22 5.2 Gruppering................................ 23 5.3 Telling................................... 23 5.4 Beskyttelse................................ 24 6 Effektivitet og ytelse 24 6.1 Komme sterkere tilbake......................... 25 6.2 Logg-strukturerte filsystemer...................... 25 A Ordliste 27 Figurer 1 Fil med sekvensiell aksess........................ 4 2 Indeks og relative filer.......................... 5 3 Katalogstruktur.............................. 6 4 Typisk filsystem-organisering...................... 7 5 Katalogstruktur med ett nivå...................... 7 6 Katalogstruktur med to nivåer..................... 8 7 Tre-strukturerte kataloger........................ 8 8 Kataloger som asyklisk graf....................... 9 9 Kataloger som generell graf....................... 10 10 a)eksisterende filsystem b)umontert partisjon............. 11 11 Effekten av å montere b) over /users i a)................ 11 12 Lagdelt filsystem............................. 12 13 Fil-kontroll Blokk (FCB)......................... 13 14 Åpning av en fil.............................. 14 15 Lesing av en fil.............................. 14 16 Skjematisk fremstilling av VFS..................... 15 17 Sammenhengende tildeling........................ 17 18 Lenket tildeling.............................. 18 19 File Allocation Table........................... 18 20 Indeksert tildeling............................ 19 21 Indeksert avbildning........................... 20 22 Avbildning ved ubegrenset størrelse................... 21 23 Tonivå indeks............................... 21 24 Kombinert løsning (UNIX)....................... 22 25 Ledig-liste................................. 23 26 Disk-hurtiglager forskjellig steder.................... 24 27 I/O uten forent buffer-hurtiglager.................... 25 28 I/O med forent buffer-hurtiglager.................... 26 Følgende kapittel er i hovedsak hentet fra [SGG02]. 2

1 Fil-konseptet - hva er en fil? En fil er et sammenhengende (contiguous) logisk adresserom - både på den måten at logisk sett følger en byte etter en annen, og at hver byte logisk hører sammen med de andre. En fil er altså en samling med byte. Grovt sett regner vi med to hovedtyper av filer: Programfiler og datafiler. Programfiler (eller kjørbare filer ) inneholder instruksjoner som kan utføres av en datamaskin. Datafiler inneholder forskjellig informasjon, og deles igjen inn i underkategoriene numeriske (tall), tegn (bokstaver) og binære. 1.1 Filstruktur I det enkleste tilfellet har en fil ingen struktur - den er bare en sekvens av ord (words) eller byte. En litt mer avansert fil kan ha en enkel post-struktur (record structure), dvs. delt inn i linjer av fast eller variabel lengde. Mange filer har imidlertid meget kompleks struktur, f.eks. formatterte dokumenter (XML, HTML, proprietære formater som MSWord.doc, etc.) og de allerede nevnte kjørbare programfiler. I praksis vil ofte de strukturerte filene nevnt over i realiteten være en ustrukturert fil, hvor strukturen oppnås ved å legge til passende kontrolltegn. Dette er bl.a. tilfellet med HTML-filer, som jo er vanlige tekst-filer ispedd koder som <head>, <body> etc. 1.2 Fil-attributter En fil vil ha en rekke attributter, og en del av disse har etter hvert blitt så naturlige for oss at vi knapt tenker over dem lenger. Fil-attributter kan være: Navn - navnet på filen er i utgangspunktet det eneste som er i menneske-lesbar form Type - for systemer som støtter forskjellige filtyper Plassering - hvor på den fysiske enheten ligger filen? Størrelse - nåværende størrelse på filen Tid, dato, bruker-id - data som brukes i forbindelse med beskyttelse, sikkerhet og bruksmonitorering All denne informasjonen om filer lagres i katalogstrukturen, og denne er igjen lagret og vedlikeholdt på disken. 3

1.3 Filoperasjoner Figur 1: Fil med sekvensiell aksess Det er mange ting man kan gjøre med filer. De kan opprettes (create), skrives til, leses fra og slettes. I de aller fleste tilfeller kreves det at man åpner en fil før man gjør noe med den, og når man åpner en fil får man etablert en gjeldende posisjon i filen. Denne posisjonen kan man endre vha. såkalt file seek, og man har også mulighet til å forkorte (truncate) en fil fra en gitt posisjon, dvs. slette alt innhold i en fil etter en gitt posisjon. Det som egentlig skjer når man åpner en fil (f.eks. Open(F i )), er at katalogstrukturen på disken gjennomsøkes etter innslagf i, og innholdet av dette (dvs. kataloginformasjonen om filen) legges i minnet. Tilsvarende vil en lukking av filen (Close(F i )) medføre at innslagf i flyttes fra minnet til katalogstrukturen (dvs. at eventuelle endringer skrives ut til disk). 1.4 Aksessmetoder Filer kan aksesseres enten ved å starte på begynnelsen av filen og lese seg fram til ønsket informasjon (sekvensiell aksess) eller ved å hoppe til ønsket posisjon i filen og kun lese informasjonen man har behov for (direkte aksess). I det første tilfellet har man typisk kommandoer som : read next Les neste blokk fra nåværende posisjon write next Skriv neste blokk fra nåværende posisjon reset Spol filen tilbake til begynnelsen Sekvensiell aksess (se Figur 1) var eneste mulighet i tidligere tider da alle filer var lagret på tape. Det har også vært konvensjon at det kun skal være mulig å skrive til slutten av en fil på tape - når man utfører en skriveoperasjon på en tape, vil det automatisk skrives et slutt-symbol (end-of-file marker) etter siste blokk. Hvis man skriver nye data midt inne i en fil, vil dermed alle de gamle dataene etter dette punktet ikke være logisk tilgjengelige. Dette betyr at det ikke vil være mulig å lese etter en skriveoperasjon (man må først spole filen tilbake). 4

Figur 2: Indeks og relative filer Ved direkte aksess vil man kunne ha følgende kommandoer: read n Les data fra relativt blokknummer n write n Skriv data til relativt blokknummer n position to n Sett nåværende posisjon til relativt blokknummer n read next Les en blokk fra nåværende posisjon, og øk denne med 1 write next Skriv en blokk til nåværende posisjon, og øk denne med 1 Hvis man skulle ønske det, ville det være trivielt å simulere sekvensiell fil-aksess med direkte aksess, som som illustreres i følgende tabell. Sekvensiell aksess Implementasjon for direkte aksess reset fp = 0; read next read fp; fp= fp+1; write next write fp; fp = fp+1 Andre aksessmetoder kan også implementeres vha. primitiver som tilbys av direkte aksess. Et eksempel er indeksert aksess, illustrert i fig. 2. Her har man en indeksfil som brukes til å lete frem til ønsket informasjon, f.eks. navnet Smith. Ved siden av navnet Smith i indeks-filen er det et tall som fungerer som en peker inn i filsystemet (dvs. en annen fil) hvor informasjon om alle som heter Smith ligger lagret. 5

2 Katalogstruktur Figur 3: Katalogstruktur Dagens harddisker er så store at de er nødt å organiseres på en eller annen måte for at man skal unngå å drukne i informasjon. Den vanligste måten å gjøre dette på er å bruke filsystemkataloger. Bruk av kataloger er hensiktsmessig for brukerne, ettersom forskjellige brukere kan bruke samme navn på forskjellig filer, bare de er plassert i forskjellige kataloger. Videre muliggjør kataloger logisk gruppering av filer, f.eks. alle Java kildefiler i en katalog, alle tekstfiler i en annen, etc. En fysisk harddisk deles gjerne inn i partisjoner (i Unix-verden ofte kjent som f.eks. /dev/hda1, /dev/hda2, etc.; i DOS-verden som c: d:... ), som vist til venstre i fig. 4. I enkelte RAID-konfigurasjoner kan det være slik at en logisk partisjon faktisk spenner over flere fysiske disker; dette kalles gjerne for striping (Mer om RAID i en senere forelesning). En partisjon vil karakteriseres ved en rekke attributter, slik som navn, type, adresse, nåværende lengde (hvor mange byte er lagret på partisjonen) og maksimum lengde. Generelt for kataloger vil det også finnes informasjon om tidspunkt for siste aksess (for å avgjøre om dataene kan skrives ut til tertiært medium for arkivering), tidspunkt for siste oppdatering (for dump/restore), eier ID (for faktureringsformål) og beskyttelsesinformasjon. Vanlige operasjoner på en katalog kan være Søk etter en fil Opprett en fil Slett en fil Rams opp (list) innholdet i en katalog Omdøp en fil 6

Figur 4: Typisk filsystem-organisering Figur 5: Katalogstruktur med ett nivå Forflytning/bevegelse (traverse) i filsystemet Bevegelse i filsystemet kan skje enten ved at man går ned i eller opp fra en underkatalog, eller at man foretar vilkårlige hopp. Det enkleste tilfellet er når man bare har ett katalognivå, som illustrert i fig. 5. Dette er imidlertid så enkelt at man knapt kan kalle det noen katalogstruktur i det hele tatt, ettersom alle filene må ligge i samme katalog. Dette blir fort problematisk i flerbruker-systemer, ettersom to brukere ikke kan bruke samme navn på to forskjellige filer (f.eks. oppgave1.txt ). Jeg kjenner ikke til systemer som bruker bare ett katalognivå. Litt mer realistisk blir det med tonivå katalogstrukturer, som illustrert i fig. 6. Her kan f.eks. hver bruker ha sin egen katalog til sine egne filer, i tillegg til at det går an å ha egne kataloger for systemprogrammer, delte filer, etc. Imidlertid er det ikke mulig å lage underkataloger i en tonivå katalogstruktur, og den enkelte bruker har ikke muligheten til å gruppere filer etter tilhørighet. Operativsystemet Sintran (til NORD datamaskiner fra Norsk Data) brukte tonivå kataloger. Alle moderne operativsystemer bruker en eller annen form for tre-strukturert katalogstruktur. Dette gir effektiv søking etter filer (selvfølgelig forutsatt at strukturen 7

Figur 6: Katalogstruktur med to nivåer Figur 7: Tre-strukturerte kataloger 8

Figur 8: Kataloger som asyklisk graf er noenlunde fornuftig) og uante grupperingsmuligheter. Tre-strukturterte kataloger aktualiserer konseptet gjeldende katalog (working directory) (eller stående drev som det het i norsk PC-litteratur på 80-tallet), hvor man først utfører en kommando (cd) for å bytte til ønsket katalog, og deretter utfører operasjoner i denne katalogen. Man har vanligvis muligheten til å angi filer enten med relativt eller absolutt sti-navn (path name); relative sti-navn tar utgangspunkt i gjeldende katalog. Ordentlige operativsystemer har filsystemer som tillater forskjellige logiske navn til både kataloger og enkeltfiler. Dette kalles gjerne for linker (se fig. 8), og er særdeles nyttig f.eks. hvis flere personer ønsker å dele samme katalog, men aksessere den direkte fra sin egen hjemmekatalog. Det gir også muligheten til å gi alias til en fil, f.eks. hvis man har en fil for hvert styrereferat (januar.doc, februar.doc... ) og et alias til siste referat som man manuelt endrer etter hvert nye møte (siste.doc). Hvis det som aliaset peker på slettes, får man noe man kaller en løs peker (dangling pointer). Dette kan man enten la være å håndtere (som er tilfellet med UNIX soft links ), eller man kan bruke en av følgende metoder: Tilbakepekere Hver fil har assosiert med seg en liste som identifiserer alle pekere som peker på filen. Når filen slettes, vil man da først slette alle pekerne. Et problem med denne metoden er at filer som mange peker på vil få en veldig stor tilbakepeker-komponent. Pekerlogg Hver fil holder rede på antallet pekere som peker på den. Her vil man formelt regne også den første referansen til filen (når den opprettes) som en peker. For å unngå løse pekere, forbyr man sletting av filen hvis antall pekere er større enn 0. Denne løsningen brukes bl.a. ved UNIX hard links. Hvis man tillater at et kataloghierarki kan være en generell graf (se fig. 9), risikerer man at man får sykler (cycles) i grafen, noe som kan skape problemer ved systematiske søk og annen traversering. Dette kan løses ved 9

Figur 9: Kataloger som generell graf Kun tillat linker til filer, ikke kataloger Rutinemessig utfør søppeltømming (garbage collection) for å fjerne sykler som måtte ha oppstått Hver gang en ny link opprettes, utfør en sykel-deteksjonsalgoritme for å avgjøre om den nye linken medfører at det oppstår en sykel. I så fall skal operasjonen feile, og linken ikke bli opprettet. 2.1 Montering av filsystemer Et filsystem svever ikke fritt over vannene, og må følgelig monteres (mount) før det kan aksesseres av operativsystemet. Filsystem bor på partisjoner, og når vi monterer en partisjon, monterer vi altså et filsystem. Et umontert filsystem limes inn i en eksisterende katalog (dvs. monteres på et såkalt monteringspunkt (mount point)), som illustrert i fig. 10 og 11. Vanligvis vil det ikke være fornuftig å velge en katalog som allerede inneholder filer som monteringspunkt, ettersom filene som ligger der før monteringen ikke vil være tilgjengelige før det nye filsystemet demonteres. Unntak kan være dynamiske kataloger som fylles over nettet, hvor man kan ha reservedata lokalt for situasjoner hvor nettet/tjenere er utilgjengelige. 2.2 Fildeling Det er vanligvis ønskelig å kunne dele filer i større eller mindre grad i et flerbrukersystem. Vanligvis ønsker vi å kontrollere hvordan dette gjøres, slik at forskjellige 10

Figur 10: a)eksisterende filsystem b)umontert partisjon Figur 11: Effekten av å montere b) over /users i a) 11

Figur 12: Lagdelt filsystem brukere får forskjellige rettigheter, avhengig av deres behov. For å oppnå dette, trenger vi et beskyttelses-system (protection scheme). Dette kommer vi tilbake til i kapittel 18. I distribuerte systemer vil filer gjerne være delt over nettverket. Vanlige måter å gjøre dette på er vha. Network File System (NFS) eller Common Internet File System (CIFS)/Samba. Distribuerte filsystemer kommer vi tilbake til i kapittel 15 og 16. 3 Implementasjon av filsystemer I avsnitt 1 har vi diskutert hva en fil er, og hvordan den er strukturert. Raskt oppsummert kan vi si at en fil er en logisk lagringsenhet som representerer en samling av relatert informasjon. Det kommer neppe som noen overraskelse at filsystemet bor på sekundær-lager, dvs. på disk. Som illustrert i fig. 12, er filsystemet typisk organisert i lag, og informasjon om hver enkelt fil lagres i en såkalt fil-kontroll-blokk (File Control Block - FCB) (se fig. 13). 12

Figur 13: Fil-kontroll Blokk (FCB) 3.1 Filsystem-strukturer i minnet Når man gjør filsystem-operasjoner i et operativsystem, trenger man visse datastrukturer i minnet for å holde styr på informasjon relatert til filene. Når man åpner en fil (fig. 14), vil brukerprosessen sende filnavnet til operativsystemet (dvs. kjernen). Katalogstrukturen vil da gjennomletes etter det aktuelle filnavnet, og av effektivitetshensyn vil deler av katalogstrukturen være hurtiglagret i kjerne-minnet. Vanligvis vil det være slik at hvis filen skulle ligge i en del av katalogstrukturen som ikke er hurtiglagret, så vil operativsystemet først legge den aktuelle biten i hurtiglageret, og deretter søke i dette. Når filen blir funnet, vil dens FCB skrives inn i systemets globale tabell over åpne filer. Deretter vil den aktuelle prosessens tabell over åpne filer få en peker til det globale innslaget. Her legger man også inn informasjon som nåværende posisjon i filen, etc. Når man skal lese fra en åpen fil (fig. 15), vil brukerprosessen ha en referanse (eller indeks) til innslaget i prosessens tabell over åpne filer (som det fremgår av fig. 15, er denne tabellen i kjerne-minnet). Som nevnt, finnes det her en peker til systemets globale åpen-fil-tabell, hvor vi har en kopi av filens FCB, og en referanse til filens fysiske plassering på disk. 13

Figur 14: Åpning av en fil Figur 15: Lesing av en fil 14

3.2 Virtuelle filsystemer Figur 16: Skjematisk fremstilling av VFS Et virtuelt filsystem (Virtual File System - VFS) er en objekt-orientert måte å implementere (eller representere) et filsystem på. En annen måte å si det på er at et VFS er en abstraksjon av begrepet filsystem. Et VFS tillater at samme systemkallgrensesnittet (Application Program Interface - API) kan benyttes for forskjellige typer filsystemer. Dette betyr at API-en er til VFS-grensesnittet, snarere enn til noe spesifikt filsystem. 3.3 Implementasjon av en katalog Hvordan implementerer man en katalog? Den enkleste måten er å ganske enkelt lage seg en lineær liste av filnavn, med tilhørende pekere til datablokker. Dette er veldig enkelt å programmere, men tidkrevende å bruke - spesielt for store kataloger. Et alternativ er å benytte en hash-tabell. Katalogen er fremdeles representert som en lineær liste, men når man skal søke etter en fil, vil man først kjøre filnavnet gjennom en hash-funksjon, og bruke resultatet som en peker inn i katalog-listen. Fordelen med denne løsningen er at søketid i katalogen blir redusert, men samtidig risikerer man kollisjoner (dvs. at to filnavn genererer samme hash-verdi), samt at dette medfører en fast maksimumsstørrelse på antall filer det er mulig å presse inn i katalogen 15

4 Tildelingsmetoder Gitt at du har en jomfruelig disk som du stapper inn i datamaskinen din - hvordan skal du tildele disk-blokker til nye filer? Vi vil presentere tre forskjellige metoder: Sammenhengende Lenket Indeksert 4.1 Sammenhengende tildeling Det enkleste er kanskje å starte på første ledige blokk, og så tildele blokker fortløpende, avhengig av hvor mange du trenger til filen. Dette kaller vi for sammenhengende tildeling (contiguous allocation), noe som fungerer bra når man allokerer diskplass første gang. Hver fil okkuperer et sett av sammenhengende diskblokker på disken, og det er sjarmerende enkelt å lese en fil - alt man trenger er start-posisjonen (blokknummer) og lengde på filen (antall blokker). Dette gir gode muligheter for vilkårlig aksess innen en fil. Imidlertid vil sammenhengende tildeling sløse med plassen, noe som følgende eksempel skulle illustrere: Vi tildeler fil A 20 blokker, fil B 16 blokker, og fil C 50 blokker. Deretter sletter vi fil B, og prøver å tildele fil D 18 blokker. Da ser vi at de 16 blokkene mellom A og C er for lite for D, og må la disse stå tomme mens vi tildeler 18 nye blokker etter fil C. Dette fenomenet kalles ekstern fragmentering, og illustreres i fig. 17. Et annet problem er at filer ikke uten videre kan vokse i størrelse når vi bruker sammenhengende tildeling. I eksempelet over kan f.eks. ikke fil A øke til 21 blokker før fil B eventuelt slettes. Mange nyere filsystemer (f.eks. Veritas File System, også kjent som vxfs) bruker en modifisert metode for sammenhengende tildeling. Man tildeler her diskblokker i såkalte extents, som er en sammenhengende klump med diskblokker. Alle filer blir alltid tildelt en extent ved opprettelse, og hvis filen er større enn dette (eller hvis den senere vokser seg større), kan flere extenter tildeles. Filen vil da bestå av en lenket liste av extenter. 4.2 Lenket tildeling Ved lenket tildeling er hver fil en lenket liste av diskblokker, som illustrert i fig. 18. Blokker kan være spredt rundt omkring på disken, og hver blokk inneholder en peker til neste kronologiske blokk i filen. Også dette er meget enkelt - alt vi trenger er adressen til den første blokken. Denne metoden gir heller ingen ekstern fragmentering, og er derfor god til å utnytte disk-kapasiteten. Imidlertid er det 16

Figur 17: Sammenhengende tildeling ikke mulig med vilkårlig tilgang innen en fil - for å finne blokk 42 må man starte på begynnelsen, finne adressen til neste blokk i den første blokken, og adressen til blokk 3 i blokk 2, osv. helt til man har lett seg fram til målet. Når vi leser fra en fil, er det imidlertid ikke vanlig å lese hele disk-blokker om gangen; vanligvis ønsker vi en enkelt byte (eller strøm av byte). Logisk ser vi gjerne filen på disken som en sammenhengende rekke byte, uavhengig av hvordan den fysisk er organisert. På denne måten kan vi operere med logiske, lineære adresser (LA). For å få til en avbildning fra den lineære adressen til den fysiske plasseringen på disken når vi bruker lenket tildeling, må vi foreta heltallstivisjon med blokkstørrelsen minus 1 (forutsetter at pekeren okkuperer bare en byte). Hvis vi antar en blokkstørrelse på 512, deler vi altså LA på 511. Denne operasjonen gir oss ut et heltallsresultat (Q) og en rest (R). Q forteller oss hvilken blokk den aktuelle byten vi leter etter ligger i, og resten R forteller oss hvor langt inne i blokken byten ligger (ettersom den første byten i blokken er pekeren, må vi regne R+1 for å finne rett byte). En velkjent variant av lenket tildeling er MS-DOS File Allocation Table (FAT), illustrert i fig. 19. Her ligger ikke pekerne i selve diskblokkene, men i en egen tabell (derav navnet). Kataloginnslaget for filen har et felt som identifiserer den første diskblokken; denne brukes som en indeks i FAT-en. Innholdet her er enten adressen (og dermed også indeksen) til neste blokk i kjeden, eller en spesiell verdi som kalles end-of-file. Her kan man kanskje spørre seg hvorfor det skulle være behov for de-fragmentering av filer i et FAT filsystem, når man ikke risikerer ekstern fragmentering? Svaret er at hvis diskblokkene til en fil er spredt vilkårlig rundt på disken, vil man tape mye tid på ekstra søking (seek), og derfor kunne Peter Norton og andre tjene store penger 17

Figur 18: Lenket tildeling Figur 19: File Allocation Table 18

Figur 20: Indeksert tildeling på defragmenteringsverktøy på 80- og 90-tallet. Til tross for at FAT er eldre enn alle hauger, er det fortsatt det vanligste filsystemet på disketter, både for Linux og Windows. 4.3 Indeksert tildeling Indeksert tildeling kan ses på som en slags viderutvikling av FAT, bare at man samler alle pekerne for hver fil i en egen blokk, og her samles pekere til hver diskblokk i filen kronologisk. Dette er illustrert i fig. 20. Indekstabellen medfører at vi får minst en blokk overhead per fil, men vi har nå mulighet for vilkårlig aksess, uten at vi får ekstern fragmentering. Med blokkstørrelse 512 kan vi med en indeksblokk ha en maksimum filstørrelse på 256K (512 512 = 256 1024) - byte eller ord eller hva det nå måtte være. Avbildningen er nesten som for sammenhengende tildeling, bare at vi nå deler den lineære adressen LA på blokkstørrelsen (her er det ingen neste-peker som stjeler plass i blokken). Heltallsresultatet Q brukes som indeks i indeks-blokken, og resten R brukes som forskyving (offset) innen blokken som indeks[q] peker på - dette fremgår med all tydelighet av fig. 21. Hvis vi ikke finner oss begrensingen på 256K filstørrelse, kan vi lage et (i prinsippet) ubegrenset system som illustrert i fig. 22. I stedet for en enkelt indeks-blokk, har vi her en lenket liste av indeksblokker. For å kunne lage en avbildning, må vi sette en grense på hvor lang kjeden skal være; 512 blokker burde være nok for de fleste 19

Figur 21: Indeksert avbildning formål i overskuelig fremtid. Beregningene må denne gangen gå i to steg: Først deler man LA på (511 512). Heltallsresultatet kaller viq 1 ; restenr 1.Q 1 angir hvilken indeks-blokk i kjeden vi skal bruke (må traversere kjeden). Vi tar når 1 og deler på 512; heltallsresultatet kaller viq 2 og restenr 2.Q 2 bruker vi så som indeks den valgte indeks-blokken, ogr 2 som forskyving innen blokken. Et alternativ er en tonivå indeks (se fig. 23), som tillater maksimum filstørrelse på 512 3. Avbildningen blir ganske lik den ubegrensede : Først deler man LA på (512 512). Heltallsresultatet kaller viq 1 ; restenr 1.Q 1 brukes som indeks i den ytterste indeksblokken. Vi tar når 1 og deler på 512; heltallsresultatet kaller viq 2 og restenr 2.Q 2 bruker vi så som indeks i indeks-blokken som ytre[q 1 ] peker på, ogr 2 som forskyving innen blokken som denne peker på. Unix bruker en kombinert løsning, som vist i fig. 24. De første (la oss si) 15 pekerne i indeks-blokken lagres i filens inode. Av disse er de 12 første pekere til direkte blokker, dvs. adresser til blokker som inneholder filens data. Hvis filen er større enn det som får plass i 12 blokker, kan man bruke den 13. pekeren. Denne peker på en indeks-blokk, og hvert innsalg i denne er en direkte peker. For enda større filer kan man bruke neste peker igjen, som peker på en indeksblokk som peker på nye indeksblokker (dobbel indireksjon). Den siste pekeren er for trippel indireksjon, og da skjønner vi at filene kan bli ganske svære dersom vi ønsker det. 5 Håndtering av ledig plass Når vi skal tildele plass til filer, må vi vite hvor vi finner ledig plass. Med en helt jomfruelig disk er det ikke så vanskelig; vi begynner bare på begynnelsen, og noterer 20

Figur 22: Avbildning ved ubegrenset størrelse Figur 23: Tonivå indeks 21

Figur 24: Kombinert løsning (UNIX) oss hvor siste blokk befinner seg - alt etter denne er ledig. I det øyeblikket vi begynner å slette filer, og filer endrer størrelse, er det ikke så enkelt lenger. En måte å holde styr på hvilke diskblokker som er ledige, er å bruke en bit-vektor (eller bit-map) som består av like mange bit som vi har blokker på disken. Hvis et gitt bit har verdien 1 1, er den korresponderende blokken ledig; i motsatt fall er den opptatt. Moderne mikroprosessorer har egne instruksjoner som raskt kan finne det første bit-et i et ord (word) som har verdi 1, f.eks. i 00000000 01011110 ville den returnert 10 (teller fra venstre). Det er også veldig lett å slå fast at et helt ord har verdien 0 (dvs. de korresponderende blokkene er fulle). Dermed er det lett å beregne adressen til den første ledige blokken: (antall bit per ord) (antall ord med verdien 0)+ (forskyvning av første 1-bit innen forste ord forskjellig fra 0). Bit-vektoren fører rimeligvis til at vi bruker ekstra plass. Hvis vi antar en blokkstørrelse på 2 12 byte og en diskstørrelse på 2 30 (1GB), vil vi måtte kaste bort 2 30 /2 12 = 2 18 bit = 32 KB på bitvektoren. Fordelen med bit-vektoren er at det er lett å få sammenhengende filer, dersom man ønsker det. 5.1 Ledig-liste Et alternativ er å ha en lenket liste av ledige blokker (free list), som vist i fig. 25. Man har en peker til den første ledige blokken, og denne har en peker til neste, osv. 1 Dette virker kanskje litt ikke-intuitivt (eller counter-intuitive) for meg; jeg ville personlig latt 0 bety ledig. Hva et gitt system faktisk velger å bruke er selvfølgelig implementasjonsavhengig, men i det følgende fortsetter vi å bruke konvenjonen introdusert i [SGG02] 22

Figur 25: Ledig-liste Dette er ikke effektivt hvis man ønsker en sammenhengende klump med blokker, ettersom man må lese hver eneste ledige blokk helt til man finner en sekvens som er lang nok. Imidlertid kan dette fungere bra i tilfeller hvor man bare tildeler en enkelt blokk, og det blir heller ingen sløsing med plassen. Lenkede tildelings-metoder som FAT kan med fordel benytte seg av en slik ledig-liste. 5.2 Gruppering En modifikasjon av ledig-listen er å lagre listen av de første n ledige blokken ei det første ledige elementet. De første n-1 adressene er adresser til ledige blokker, mens adresse n er en peker til en ny blokk som peker på de neste n ledige blokkene, osv. På denne måten kan man raskt finne adressene til et stort antall ledige blokker, i motsetning til den vanlige ledig-listen. 5.3 Telling Nok en variant er å lagre adressen til den første ledige blokken, og så antall sammenhengende ledige blokker som følger etter den. Dette vil være en effektiv måte å gjøre ting på så lenge antallet sammenhengende blokker gjennomsnittlig er større en 1 (dvs. at det lite ensomme ulver på disken). 23

5.4 Beskyttelse Figur 26: Disk-hurtiglager forskjellig steder Uavhengig av om man bruker en ledig-liste eller et bit-map, må denne informasjonen beskyttes. Bit-map-et må lagres på disk, og da risikerer man at kopien i minnet og på disken avviker hvis endringer skjer rett før et system-kræsj. Man kan på ingen måte tillate en situasjon der bit[i]=0 (ikke ledig) i minnet mens bit[i]=1 (ledig) på disk, dvs. at blokken er allokert i minnet, men ikke på disken. Hvis systemet skulle tryne akkurat da, ville det komme opp og tro at blokk i er ledig, mens den i virkeligheten er allokert, og i bruk av en fil. Neste gang en prosess ber om diskplass vil blokk i kunne tildeles til denne, og den opprinnelige filen blir inkonsistent/korrupt. Løsningen er at når man skal allokere blokk i må man først sette bit[i]=0 på disk, deretter allokere blokk i, og så til slutt sette bit[i]=0 i minnet. 6 Effektivitet og ytelse Effektivitet i et filsystem er avhengig av disk-allokering og katalog-algoritmer, og også av hvilke typer data som lagres i filens kataloginnslag. Mekanismer som kan påvirke ytelse inkluderer bruk av disk-hurtiglager (Disk cache), frigjøring av plass bakover og lesing framover (read-ahead), og bruk av RAM-disk. Sistnevnte er mest aktuelt i forbindelse med midlertidig mellomlagring, f.eks. i forbindelse med kompilering. Som det fremgår av fig. 26, kan data fra disk både hurtiglagret i hovedminnet (RAM) og på dedikerte buffere på disk-kontrolleren. Moderne teknikker for virtuelt minne (Virtual memory techniques) medfører at man gjerne hurtiglagrer hele sider fra minnet, snarere enn disk-blokker. Også minneavbildet I/O (memory-mapped I/O) bruker side-hurtiglager (page cache). Rutinemessig I/O via filsystemet bruker imidlertid det gode, gammeldagse buffer-( dvs. disk-) hurtiglageret, noe som fører til problemet illustrert i fig. 27 - de hurtiglagrede 24

Figur 27: I/O uten forent buffer-hurtiglager sidene bufres to ganger. Et forent buffer-hurtiglager (unified buffer cache) bruker samme side-hurtiglager til å hurtiglagre både minne-avbildede sider og ordinær filsystem I/O. 6.1 Komme sterkere tilbake Datasystemer har det som kjent med å tryne, og i henhold til Murphy s lov skjer dette vanligvis på det verst tenkelige tidspunkt. Dette betyr at det går hardt ut over filsystemet, og etter system-kræsj er det vanligvis behov for konsistens-sjekking som består i å sammenligne data i katalogstrukturer med korresponderende data-blokker på disken. Hvis man finner inkonsistenser, vil disse bli forsøkt fikset. Det regnes for fornuftig å rutinemessig foreta backup til tertiært lagringsmedium, slik at man i de tilfeller hvor man får feil i filsystemet som ikke automatisk kan repareres, kan gjenvinne de tapte filene fra backup. 6.2 Logg-strukturerte filsystemer Logg-strukturterte (log-structured eller journaling) filsystemer registrerer hver oppdatering til filsystemet som en transaksjon. Alle transaksjoner skrives til en logg. En transaksjon regnes for gjort endelig (committed) i det øyeblikket det er skrevet til loggen. Imidlertid er det mulig at selve filsystemet ikke er oppdatert enda. Transaksjonene i loggen skrives asynkront til filsystemet. Når filsystemet modifise- 25

Figur 28: I/O med forent buffer-hurtiglager res, fjernes transaksjonen fra loggen. Hvil filsystemet kræsjer, må alle gjenværende transaksjoner i loggen likevel utføres. 26

A Ordliste Her følger en alfabetisk liste over mer eller mindre egendefinerte norske ord på velkjente engelske begreper. agent-annonsering Agent Advertisement agentoppdagelse Agent Discovery applikasjonsnivå portner Application Level Gateway besøksagent Foreign Agent dataflyt flow dobbelstakk dual stack endesystem host eller end system flytmerke flow label fordeling scheduling forskyvning offset grensesnitt interface (som i network interface card) hjemme-agent home agent nabo-oppdagelse Neighbor Discovery nettverksadresseoversetting Network Address Translation planlegger scheduler planlegging scheduling rekkevidde scope ressursfordeling scheduling ruter router ruter-annonsering router advertisement ruter-forespørsel router solicitation ruting routing sammenhengende contiguous (burde kanskje vært tilstøtende ) skank trailer skolt header stamnett backbone sykel cycle systemkall-grensesnitt Application Program Interface 27

sømløs seamless tjener server tjenestekvalitet Quality of Service vandring roaming Referanser [SGG01] Abraham Silberschatz, Peter Baer Galvin, and Greg Gagne. OSC slides. http://cs-www.cs.yale.edu/homes/avi/os-book/osc/slide-dir/index.html, 2001. [SGG02] Abraham Silberschatz, Peter Baer Galvin, and Greg Gagne. Operating Systems Concepts. John Wiley and Sons, 6th edition, 2002. 28