Öppna filer och filsystem i PintOS Hemuppgift TDDI8, /0-03 Almquist Mathias (matal09) Nguyen Johan (johng86) Hamzic Mirza (mirha348) Timliden Erik (eriti930) INLEDNING PintOS är ett operativsystem utvecklat på Stanford University och används världen över för att hjälpa studenter inom grunderna i operativsystems programmering och tillhörande felsökning. Vi har fördjupat oss inom filer och filsystem i PintOS, förklarat hur det fungerar och hur det kan förbättras. KATALOG STRUKTUR OCH FILHANTERING I boken beskrivs katalogstrukturen som antingen en linjär lista med poster eller att posterna lagras i en hashtabell. Fördelen med den linjära listan är att den är simpel att implementera men är dock ineffektiv eftersom att söka fram poster kan tvinga systemet att söka igenom varje post i listan för att hitta rätt fil. Hashtabellen är svårare att implementera men erbjuder effektivare sökning då en hashfunktion tar fram rätt post snabbare. I PintOS finns en rotkatalog med plats för 6 poster, vilket innebär att man inte kan ha fler än 6 filer på systemet. Rotkatalogens inode pekar ut startblocket där alla 6 poster finns på disk. En post innehåller filnamn med sektorn för tillhörande inode. För att hitta en fil så söker systemet linjärt genom rotkatalogens poster tills posten med rätt filnamn hittas. Systemet har då hittat filens inode och kan då börja läsa eller skriva till disk. Om ingen post med matchande filnamn hittas så returnerar den att ingen fil hittats. FILE CONTROL BLOCK OCH INODE Inode är en förkortning av index node, en datastruktur som i PintOS används för att sammankoppla en fil eller katalog med dess system-wide open table data. Inoden är i PintOS en pekare till första sekvensen bytes med metadata. Pekaren är sammankopplad med filnamnet som ett heltal, som båda finns lagrade i process file table. I PintOS används inodes även som File Control block (FCB). FCB håller reda på info om filer, samt en pekarstruktur på de olika blocken i minnet. Det finns åtskilliga vägar att definiera och kontrollera inodes, t.ex. WAFL, där en lista root inode innehåller pekare till en lista inode file fylld med pekare till bl.a. free block map, free inode map, file in the file system för filen. I PintOS blir inode en extra rättighetskontroll då en process inte kan få tillgång till data utan rätt inode-pekare. För att effektivisera tidsåtgången bör inode och informationen om filen lagras nära varandra på minnet, inode bör även lagras i cachen för att vara så tillgänglig som möjligt.
SYSTEM-WIDE OPEN FILTABELL Datastrukturen som används för system-wide open file table är en struct list open_inodes, den innehåller alla öppna inodes. De funktioner som manipulerar struct list open_inodes finns deklarerade inode.[hc]. I PintOS är system-wide open file table en list med inodes struct list open_inodes. Det funkar så att när vi vill öppna en fil så kollar vi om den finns i rotkatalogen med funktionen dir_lookup som finns deklarerat i dir.[hc]. Om inoden inte redan finns så läggs den till i open_inodes listan, om den är öppen så inkrementeras open_cnt. Dir_lookup returnerar sedan en inode-pekare som pekar på rätt inode för filen. Om den inte hittar filen i rotkatalogen sätter den inode pekaren till null. PER-PROCESS FILE TABLE Per-Process file table är implementerad med en struct map som innehåller en array med filepekare som i sin tur innehåller en inode-pekare och läspositionen. Funktioner för att manipulera struct map finns i flist.[hc]. När en process vill öppna en fil lägger den till en file pekare i sin tabell (struct map). Allt förarbete är redan gjort i System-wide open file table. Det enda processerna behöver göra är att kolla i system-wide open file table efter filen och skapa ett file- objekt som pekar till rätt inode från system-wide open file table. Tabellerna finns lagrade i arbetsminnet, Perprocess file table skapas när en process körs och System-wide open file table laddas in under uppstart. Tabellerna behövs för att hantera datorns resurser på ett effektivt sätt. Processfile table System-wide open table 0 0
FREE-SPACE MANAGEMENT En viktig del av filsystem är att se till så att man aldrig skriver över upptagna block och dessutom så måste man kunna återanvända block som frigjorts pga. borttagning av filer. Det finns olika metoder för att hålla reda på vilka block på disken som är lediga för användning. Nedan följer några av de vanligaste metoderna: Bitmap Metoden som PintOS använder sig av är bitmap. Den går ut på att varje block representeras av en bit som är lagrad i en array eller liknande. Om blocket är ledigt så är biten och om den är upptagen så är biten 0. Fördelar med denna metod är att den är simpel och det är snabbt och effektivt att hitta ett visst antal konsekutiva bitar som är lediga. Nackdelar med denna metod är att bitmappen kan ta upp mycket lagringsutrymme och snabb åtkomst kan kräva att den är lagrad i så snabbt minne som möjligt. För väldigt stora diskar kan bitmappen bli extremt stor och därmed inte få plats i main memory vilket gör åtkomst långsam. I PintOS finns en struct bitmap och tillhörande funktioner i filerna bitmap.[ch]. Det finns även funktioner i filerna free-map.[ch] som utnyttjar Bitmappens funktioner. Bitmap innehåller en unsigned long array där varje unsigned long i sin tur simulerar en array av bitar. När en fil behöver nya block så används funktionen free_map_allocate som med hjälp av bitmappen, allokerar ett visst antal konsekutiva block. Free_map_allocate är en av de viktiga funktionerna eftersom att den är en stor del av PintOS allokeringsalgoritm. Alternativa metoder Andra exempel på metoder är linkad list och grouping. Dessa löser bitmappens problem, men har sina egna nackdelar. Linked list är en metod där alla lediga block länkas ihop för att bilda en länkad lista. En pekare på det första lediga blocket sparas på någon speciell plats på disken. Det här första blocket har sedan en pekare på nästa lediga block, och så vidare. Eftersom pekarna bara tar upp ledig plats så förlorar vi inget lagringsutrymme med denna metod. Det är dock ineffektivt att traversera genom listan eftersom vi då måste gå igenom varje blocks pekare för att hitta rätt block. Grouping är en metod som liknar linked list, men som förbättrar effektiviteten vid traversering. Här lagrar det första blocket adresserna för n andra block. De första n av dessa är faktiskt lediga men det sista blocket lagrar adresserna för n nya block och så vidare. Bitmap är ett bra alternativ för PintOS eftersom disken är liten vilket medför att bitmappen blir liten. Den kan då lätt sparas i ett minne med snabb åtkomsthastighet. BORTTAGNING AV ÖPPNA FILER Då en öppen fil blir borttagen fortsätter alla processer som har en fildeskriptor för denna fil använda denna fildeskriptorn. Detta betyder att processerna kan läsa från och skriva till filen. Filen kommer inte ha något namn, och andra processer kommer inte kunna öppna den, men den kommer fortsätta finnas. Filen kommer inte tas bort innan alla fildeskriptorer som hänvisar till den är stängda eller innan datorn stängs av/startas om. 3
MINNESALLOKERING PintOS använder contiguous allocation, det finns andra allokeringsmetoder som t.ex. linked allocation och indexed allocation. En nackdel med contiguous allocation är att det skapas external fragmentation när block tas bort, dock är den väldigt enkel att implementera. Indexed allocation löser problemet med external fragmentation, ett annat problem med längre lästider kan uppstå då program med flera block tar långtid att gå från block till 8. Linked allocation löser också external fragmentation men problemet blir nu att pekare kan skapas huller om buller, att block 7 pekar till 5 vilket tar lång tid att läsa. Alla olika allokeringsmetoder har problem med internal fragmentation som enbart kan lösas genom mindre block. En sammanslagning av indexed allocation och contiguous allocation löser problemet med en linjär genomgång av alla block för att hitta rätt i contiguous allocation. Ett indexblock på första positionen löser detta och bör innehålla metadata som filstorlek och blockposition. FÖRBÄTTRINGAR I PINTOS PintOS som operativsystem har sina brister, i dagsläget används contiguous allocation vilket medför external fragmentation, vilket kan lösas med indexed allocation. För att indexed allocation ska fungera så bra som möjligt bör vi ändra på pekarstrukturen och utföra små förändringar i minnesalkokeringen. PintOS bör efterlikna Unix med inode-pekare och använda Combined scheme, istället för en pekare till en sekvens bytes bör flera pekare finnas som markerar de olika datablocken (se bilaga ). Det är lätt att lokalisera en viss position i en fil med logiska adresser, som är uppdelade till frame nummer och offset. Med blockstorleken som 5 bytes innebär detta om datasystemet vill komma åt på en fil ligger mellan 536-048 bytes så kan systemet enkelt följa den tredje directpointer. För att minimera antalet block och blockläsningar bör vi skapa möjligheten att införa clusters, en samling block för att effektivisera vid möjlighet, istället för att enbart öka storleken på varje block som skulle skapa ytterligare internal fragmentation som är nackdelen med Indexed allocation. För att kunna skapa hardlinks måste vi implementera en reference counter i inoden. Den håller koll på antalet hardlinks skapade, när reference counter når noll kan filen tas bort. SAMMANFATTNING PintOS kan gynnas mycket av små ändringar som i praktiken är omständligare att implementera än dagens lösningar. Eftersom PintOS är ett operativsystem utvecklat för att lära operativsystems programmering på en grundläggande nivå bör den även stanna där. I mer avancerad operativsystems programmering bör PintOS utvecklas till att använda andra allokeringsmetoder och mer komplexa filsystem. REFERENSER. Ben, Pfaff. PintOS, 004.. Stanford PintOS documentation, http://www.scs.stanford.edu/07aucs40/pintos/pintos.html#sec_contents /0-03 3. Silberschatz, Galvin, Gagne. Operating System Concepts: 8 th edition, 009. 4
Bilaga, förbättrad PintOS inode struktur. 5