Operációs rendszerek tárkezelés.

Átírás

1 Operációs rendszerek tárkezelés. Tárak hierarchiája. Memóriakezelés: rögzített és dinamikus partíciók, virtuális memória fogalma. Lapozás és szegmentálás. Lapcserélési algoritmusok, munkahalmaz. Bemenet/kimenet ütemezése és a kiszolgálási idő csökkentése. Lemezterület-szervezés, fizikai és logikai formázás, partíciók. Redundáns tömbök, kötetkezelő rendszerek. Állományrendszerek szolgáltatásai és megvalósításuk. Blokkfoglalási módszerek, szabad tárterület nyilvántartása, naplózás. Tárak hierarchiája. A tár fogalma: Adatokat tárol, amelyek lehetnek programkódok vagy azok adatai (Neumann-elv: ezek közös tárban tárolhatóak). Az adatok elérhetjük írás/olvasás/végrehajtás módban, címzés vagy asszociatív lekérdezés útján. Az egyszerre elérhető adatok mennyiségi minimuma általában egy bájt, maximum akár több MiB. Tárak egymásra épülése: Vagyis a gyakran használt adatokat célszerű minél magasabb szinten tárolni. A szintek között létezhetnek különböző gyorsítótárak (pl.: háttértárról archiváláskor köztes memória). A szintek közötti adatcserét végezheti a felhasználó (pl.: archiválás: háttértár archív tár), program (pl.: regiszter memória), operációs rendszer (pl.: regiszter memória háttértár), hardver (pl.: az előbb említett gyorsítótárak). Memóriakezelés: rögzített és dinamikus partíciók, virtuális memória fogalma. Memóriakezelés feladata: Programok betöltése a memóriába, általuk használható területek biztosítása, valamint a memória megosztása a különböző folyamatok között. 1

2 Programok betöltése: Program beolvasása háttértárról a memóriába, ott annak elindítása. A programoknál bázisregisztert használunk (a programok meghatározott memóriacímekkel dolgoznak, betöltéskor ezeket a címeket a bázisregiszterhez adjuk hozzá, így nem kell mindig újra számolni az összes címzést, csak eltolni). A memóriában lévő adatokat vagy a program állítja elő, vagy a háttértárról töltődnek be, mindkét esetben kell terület, amin elférnek. A bázisregiszterek számolása/közlése, és a területfoglalása lehetőségének biztosítása az operációs rendszer feladata. Particionálás: Szó szerint: részekre osztás. Rögzített, fix partíciók: A rendszergazda definiálja az egyes partíciókat (azok számát, azok méreteit). A legelső partíción fut az operációs rendszer. Minden folyamat olyan partícióba kerül, amiben elfér, ha nem fér el sehol, akkor a háttértáron várakozik. Rögzített partíción alkalmazott algoritmusok: 1. Partíció felszabadul megkeressük a legnagyobbat, ami még belefér. Problémája: kiéheztetés (a partíció méretét alulról közelítő folyamatok előnyben vannak) 2. Partíció felszabadul ami befér, annál számlálót növelünk, és e szerint tesszük be az újat. 3. Minden folyamatot úgy tekintünk, hogy ő akkora, mint a legkisebb partíció, amibe még befér. Dinamikus partíciók: Az operációs rendszer előre rögzített méretű partíción van, az összes többi partíció dinamikusan foglalódik/szabadul fel. Az operációs rendszer keres a folyamatnak egy elég nagy helyet, és ott létrehoz egy partíciót, melyet a folyamat befejeztével meg is szüntet. Ha nincs elég nagy egybefüggő terület, akkor a folyamat kénytelen várakozni (amíg nem lesz elég nagy hely, vagy amíg nem történik egyfajta töredezettség-mentesítés ). Az operációs rendszernek kell a partíciókat és a szabad területek nyilván tartania (a szabad területeket esetenként összeolvasztania), valamint a megfelelő szabad területet kiválasztani az új folyamatoknak. Dinamikus partíciók jellemző problémái: Pazarlás: kis folyamatok elfoglalják a nagy szabad helyeket a nagy folyamatok elől. Elaprózódás: sok kis szabad terület marad, amelyben nem férnek el új folyamatok, hiába nagy az összesített szabad terület. Dinamikus partíciókon alkalmazott algoritmusok: Alapvetés: bájtok helyett blokkokban foglaljuk a területet (a néhány bájtosra aprózódás csak lassít). 1. First Fit: a szabad-listából az első megfelelő méretű részt választjuk. Előnyei: gyors és egyszerű. Hátrányai: a memória eleje elaprózódik növekvő keresési idő. 2. Next Fit: a legutóbb létrejött folyamat utáni első megfelelő méretű részt választjuk. Előnyei: gyors és egyszerű, a memóriát egyenletesen osztja el, egyenletes keresési idő. Hátrányai: könnyen pazarol és aprózódik el. 3. Best Fit: azt a legkisebb szabad területet választjuk, amiben még elfér. Előnye: nem pazarol. Hátrányai: lassú, könnyen elaprózódik. Javítása: alsó korlát a fennmaradó szabad részek méretére. 4. Worst Fit: a lehető legnagyobb területet választjuk. Előnye: nem aprózódik el. 2

3 Hátránya: lassú, könnyen pazarol. Javítása: lista helyett kupacban tároljuk a szabad területeket, maximalizáljuk a lefoglalt méretet a folyamat méretének függvényében. Virtuális memória: Előfordulhat, hogy egy adott program egyáltalán nem fér be a memóriába. A mozgatás a háttértár és a memória között viszont nagyon időigényes feladat. Észrevehetjük, hogy a programok rövid idő alatt csak kis részét használják a tárterületnek, valamint hogy az operációs rendszer felelőssége nagy (biztosítania kell, hogy a program ne nyúljon ki a partícióból; ha a partíció túl kicsi, akkor dinamikusan hozzá kell foglalni, stb.). Ötlet: a programok által látott memóriaterület különbözzön a fizikai memóriától. A program által látott részt nevezzük virtuális memóriának. A virtuális memória követelményei: Minden program saját memóriaterületet lásson (mintha minden memória az övé volna), bármely címre lehessen hivatkozni, ahol is az adatok permanens tárolódjanak (akárcsak a fizikai memóriában), a program ne tudjon semmit arról, hogy hogyan van ez megvalósítva, a hatékonyság ne romoljon drasztikusan a fizikai memóriához képest. A virtuális memória megvalósítása: A virtuális és a fizikai memóriát is felosztjuk részekre, ezeket egymáshoz rendelhetjük. Ha a folyamat olyan memóriaterületre hivatkozik, amihez még nincs fizikai memória rendelve, akkor kivétel keletkezik ennek kezelését az operációs rendszer végzi, amely folyamán hozzárendel egy fizikai memória részt. Minden program saját címtárral rendelkezik, az ő címei nem hivatkozhatnak másik folyamat fizikai memóriájára, kivéve bizonyos speciális eseteket (pl.: operációs rendszer kódja, adatai; kommunikációs adatok, stb.). A leképezés során a címpárokat tárolni kell, ezt tehetjük: byte-onként: rugalmas, de a címtáblázat nagy, rögzített méretű darabonként: lapozás, változó méretű darabonként: szegmentálás. Lapozás és szegmentálás. Lapozás: A virtuális és a fizikai memóriát is egyenlő méretű darabokra osztjuk: virtuális memória lapok, fizikai memória lapkeretek. Egy lappal csak akkor dolgozhatunk, ha keretbe foglaltuk, de a keretek száma kevesebb, mint a lapoké. Egy lapon belüli címek egy lapkereten belüli címekké fordítódnak. A lapok mérete általában kettő hatvány. Laptábla: A lapok és lapkeretek egymáshoz rendeléseit tartalmazza, minden folyamatnak van egy. A laptábla a lapcím szerint indexelt, mezői üresek vagy a lapkeret címét tartalmazzák. Ha üres laphiba kivétel (erre a kivételkezelő elhelyezi egy lapkeretben a lapot). Ez mindig fault, vagyis a kivételt okozó utasítás a kivétel kezelése után újra végrehajtódik. A gyakori lapcím lapkeret párokat egy gyorsítótárban tároljuk. Lapméret problematikája: Ha nagy a lapméretünk, akkor kicsit a laptábla, de belső elaprózódás lép fel (a kisebb folyamatok több memóriát kapnak, mint amire szükségük lenne). Ha kicsi a lapméret, akkor kevés memória 3

4 veszik kárba, ellenben nagy a laptábla, ami viszont sok memóriát eszik. Megoldás: kettős szintű laptáblázat. A lapcímtár tartalmazza a laptáblákat, ez mindig a memóriában van, a laptáblák pedig lapokon tárolódnak. Optimális esetben egy laptábla egy lapot foglal el (közös kivételkezelés a laphibával). A cím mellett lehetőségünk van egyéb információk tárolására is: jelenlét, védelmi információk (milyen szintről elérhető a lap), hozzáférési mód (írás/olvasás/végrehajtás), gyorsítótár információk, hivatkoztak-e már a lapra, írtak-e már a lapra. Folyamatok elszigetelése: Nem teljes, mert az operációs rendszer kódja és adatai minden folyamat laptáblájában megtalálhatóak. Ezen kívül azonos programot futtató folyamatok esetén a programkódot elég egyszer bemásolni, valamint a folyamatok között kommunikáció gyakran hatékonyabb közös memóriával, mint rendszerszolgáltatásokkal. Szegmens: Tetszőleges méretű lineáris címtér. Mindnek van egy egyedi azonosítója, amelyeket a fizikai memóriacímekhez a szegmenstábla alapján rendeljük. Szegmentált memória: több lineáris címtérből álló virtuális memória (pl.: egy program különböző adatszerkezetei külön szegmensekben helyezhetőek el). Előnyök a lapozáshoz képest: Rugalmas: adatszerkezetenként független bővítés. Jobb illeszkedés a programszerkezethez: a munkahalmaz könnyebben definiálható. A szegmensek lehetnek különbözőek (csak olvasható/írható/végrehajtható, kombinációk, stb.). Könnyebben megvalósítható adatmegosztás a folyamatok között. Hátrányai a lapozáshoz képest: Hosszabb címek, bonyolultabb algoritmusok, nehezebb védelem (mi van, ha egy rendszerhívásnak egy a rendszer területén lévő adatszerkezet címét adjuk át? biztonsági rés). Szegmentálás megvalósítása: A dinamikus partíciók algoritmusait alkalmazzuk a szegmensek elhelyezéséhez, a lapozási algoritmusokat pedig a szegmensek cseréléséhez (de őket módosítani kell: néha több szegmenst ki kell dobnunk, a nagy szegmensek kidobása költséges, a kicsiket meg nem éri meg kidobni). Szegmentálástáblázat: A szegmensek leíróit deszkriptoroknak hívjuk. Ezek tartalmazzák a szegmens fizikai címét; típusát (kód/adat); hogy benne van-e a fizikai memóriában; hivatkoztak-e rá, mióta benn van; a szegmens elérési módját, védelmi szintjét. A deszkriptortábla indexeit szelektoroknak hívjuk. A szegmensregiszterek egy-egy szelektort tartalmaznak. Előnye: nem kell mindig explicit megadni a szelektort rövidebbek a címek. Minden folyamatban külön deszkriptortáblája van globális vs. lokális (rendszer vs. folyamat). A szelektorokban is állítható a védelmi szint. Szegmentálás lapozással: Általában a szegmensméret jóval nagyobb, mint a lapméret. Ha a szegmensek elejét és végét laphatárra igazítjuk, akkor csak a lineáris memóriában kell mozgatni adatokat (laptáblák átírása). Ekkor a cserélő algoritmusokat két szinten alkalmazhatjuk: az alsó szinten lapcserék, a felső szinten szegmenscserék. 4

5 Lapcserélési algoritmusok, munkahalmaz. Laphiba kezelése: A hiányzó lapot be kell töltenünk vagy létre kell hoznunk egy üres lapot. Ha van üres lapkeret, ezt megtehetjük, ha nincs, akkor ki kell dobnunk egy lapot, a kérdés, hogy melyiket. Mivel a laphiba kezelése sok erőforrást igényel, a cél a minél kevesebb laphiba. Az optimális algoritmus: Cél: Minél kevesebb laphiba Megvalósítás: mindig azt a lapot dobjuk ki, amelyre a legkésőbb lesz szükség. LRU (Last Recently Used) algoritmus: Az optimális algoritmus a valóságban megvalósíthatatlan, mert nem tudjuk előre, hogy melyik lapra fognak a legkésőbb hivatkozni (nem vagyunk jósok). Amit viszont tudunk: egy program rövid időn belül kis memóriaterületet használ ugyanazokra a lapokra hivatkozik sokszor amire már régen hivatkozott, arra mostanság nem is fog azt kell kidobni, amire a legrégebben hivatkozott. Ezzel a probléma: hogyan követjük nyomon a hivatkozásokat? Ha az operációs rendszer teszi ezt, akkor nagyon lelassulna, ha hardveresen oldjuk meg, akkor nagyon bonyolult lenne. Továbbá: hol tároljuk el az utolsó hivatkozás idejét? Ez nagyon megnövelné a laptábla méretét. Ezek következtében az LRU-t is csak közelítjük. FIFO (First In First Out) algoritmus: Az LRU legegyszerűbb közelítése: azt dobjuk ki, ami legrégebb óta benn van. Megvalósítható sor adatszerkezettel, vagy körben járó lapkeretmutatóval (számlálóval). Problémája: a program egyszerre több, nem diszjunkt laphalmazzal dolgozik, ezt az LRU figyelembe veszi, de a FIFO nem. Bélády-anomália: Bizonyos lapcserélési algoritmusoknál (pl.: FIFO) előfordulhat, hogy több lapkerettel több laphiba történik. NFU (Not Frequently Used) algoritmus: A laptáblákban van egy bit, amit mutatja, hogy egy lapra írtak-e már. (A accessed/r referenced). Ötlet: bizonyos időközönként vizsgáljuk meg ezt a bitet, értékét adjuk egy számlálóhoz, majd nullázzuk ki. Laphibánál a legkisebb számlálóval rendelkező lapok dobjuk ki. Problémája: ha egy lapra sokszor hivatkoztak, de utána hosszú ideig nem, akkor még mindig előnyt élvez. Javítása: ne hozzáadjuk a bitet, hanem a számlálót toljuk el jobbra, és az első bitnek írjuk be az új értéket. Belátható, hogy NFU mentes a Bélády-anomáliától. Javított NFU problémái: túl hosszú számláló nem fér el, a nullázás és az eltolás költséges művelet. SC (Second Chance) algoritmus: FIFO legjelentősebb problémája: régen bent lévő lapot akkor is kidobja, ha nem régen hivatkoztak rá. Ezt a hibát kiküszöbölhetjük, ha megnézzük, hogy nemrég hivatkoztak-e a lapra, ha igen, akkor adunk neki egy újabb esélyt (nullázzuk a bitet és a lapot a sor végére tesszük). Módosított lapok Módosított lapcserélési algoritmusok: Lapcserék költségei különbözőek lehetnek: ha olyan lapot dobunk ki, amit csak olvastak, de nem módosítottak, akkor nem kell a lemezre írnunk. A laptáblákban gyakran van egy bit, ami jelzi, hogy írtak-e a lapra (D dirty/m modified). A korábbi algoritmusok kiegészíthetőek, hogy olyan lapot próbáljanak kidobni, amire még nem írtak. 5

6 Globális vs. Lokális lapozás: A lapozási algoritmusokat alkalmazhatjuk globálisan (folyamatfüggetlenül), vagy lokálisan (minden folyamatra külön-külön). Munkahalmaz: A folyamat által rövid időn belül használt lapokat nevezzük a szükséges munkahalmaznak. A folyamatnak jutó lapkereketek nevezzük az aktuális munkahalmaznak. Ha a szükséges nagyobb, mint az aktuális, akkor sok laphiba; ha az aktuális nagyobb, mint a szükséges, akkor pazarlunk. Megoldás: statisztika a laphibákról. Többszintű lapozás: A lokális algoritmusok eleve kétszintűek (alsó szinten lapcserék, felső szinten a munkahalmaz méretének állítása). De szintezhetünk máshogy is: alsó szinten a lokális lapcserék nem a háttétárra, hanem egy közös tárolóba történhetnek, felső szinten pedig globális lapcserék ebből a tárolóból. Ekkor laphiba kivétel történhet akkor is, amikor a lap még a közös tárolóban van gyorsabb visszatöltés. Előlapozás: A kivételek feldolgozása erőforrás igényes, és a háttértárról is megéri egyszerre nagyobb adatmennyiséget beolvasni. Ezért végzünk előlapozást: betöltünk olyan lapokat is, amikre még nem történt hivatkozás (pl.: a program első lapjai induláskor, és statisztikák alapján, hogy melyik lap után melyik lapot szokta a folyamat hivatkozni). Bemenet/kimenet ütemezése és a kiszolgálási idő csökkentése. I/O kérés szerkezete: Egy I/O kérés tartalmazza annak fajtáját (írás vagy olvasás), a kért blokk számát (vagy fizikai címét), a pufferterület címét a memóriában, a mozgatandó bájtok számát. I/O ütemezés feladata: Egy adott lemezegységet általában egyszerre több folyamat akar használni. Az ütemező dönti el, hogy melyiket hajtja végre először, amíg a többi várakozik. Ehhez figyelembe kell vennie a következőket: fejmozgási idő (seek time) amíg a fej az adott cilinderhez mozog, elfordulási idő (rotational latency) amíg a lemez az adott szektort pörgeti a fej alá, az átlagos válaszidő minél kisebb, a sávszélesség minél nagyobb legyen, a CPU igényt ne növelje nagyon (minél kisebb overhead). 6

7 Beépített ütemezés: A modern lemezegységekben a fejmozdulási idő alig haladja meg az elfordulás miatti késlekedést. Az általános algoritmusok csak a fejmozgást tudják figyelembe venni, mivel az elfordulás az tervezés-specifikus. Ezért vannak lemezegységek, amelybe beépítenek egy ütemezőt, ez az adott modellhez illeszkedő algoritmust tud alkalmazni. Az operációs rendszer ömlesztve továbbítja ennek az ütemezőnek az I/O kéréseket. Kiszolgálási idő csökkentése: Az ügyes szervezéssel sokat érhetünk el. Például az összetartozó adatok legyenek egymás mellett; a leggyakrabban használt adatok legyenek a lemez közepén (vagy legyenek több példányban tároltak); olvassunk/írjunk egyszerre több blokkot; a szabad memóriát használjuk gyorsítótárnak; tömörítéssel csökkentsük az I/O műveletek számát (bár ezzel nő a CPU igény). I/O ütemező algoritmusok: FCFS (First Came First Served Sorrendi ütemezés): a kéréseket a beérkezés sorrendjében szolgáljuk ki. Problémája: hosszú válaszidő. Előnyei: a válaszidő statisztikai szórása kicsi, igazságos (nincs kiéheztetés). SSTF (Shortest Seek Time First Lusta ütemezés): azt a kérést szolgáljuk ki, amihez a legkevesebb fejmozgás szükséges. Problémája: fennáll a kiéheztetés veszélye (főleg hosszú várakozási sornál), a válaszidő statisztikai szórása nagy. Előnyei: A sávszélesség látványosan nagy. SCAN (Lift ütemezés): pásztázó algoritmus a fej folyamatosan pásztáz a lemez egyik szélétől a másikig és az éppen útba eső kérést szolgálja ki. Problémája: a várakozási idő statisztikai szórása viszonylag nagy. Előnyei: a sávszélesség nagy és a kiéheztetés is ki van zárva. N-SCAN (N lépéses pásztázó): egy irányba mozogva csak N olyan kérést szolgál ki, ami már az adott irányba való mozgás kezdetén megvolt. C-SCAN (egyirányú pásztázó): a kérések kiszolgálása mindig csak az egyik irányú mozgásnál történik, a másik az üresjárat LOOK (előrenéző): egy irányba mozogva addig megy, amíg már az adott irányban nincs több kérés, ekkor megfordul a fej. Kis terhelésnél a SCAN, nagyobb terhelésnél a C-SCAN szokott a leghatékonyabb lenni. Előlegező ütemezés (Anticipatory I/O scheduling): Az ütemezés heurisztikus javítása. Megfigyelhető, hogy gyakran egymás utáni blokkokat olvasnak/írnak a folyamatok (szekvenciális olvasás). Minden ilyen művelet után várakozzunk egy kicsit (néhány millikszekumdum). Ha tudjuk, hogy nem szekvenciális műveletet végzünk, akkor viszont ne várakozzunk. 7

8 Lemezterület-szervezés, fizikai és logikai formázás, partíciók. Lemezegység felépítése: Fizikailag: Megjegyzések: a firmware elfedheti a valós felépítést; a lemez közepe felé csökkenhet a szektorok száma; CD/DVD esetén nincsenek sávok, a szektorok egy spirálisan feltekert egydimenziós tömbben vannak. Logikailag: blokkok egydimenziós tömbje (egy blokk általában 256 vagy 512 byte). Fizikai formázás: A sávok és szektorok elválasztása a fizikai adathordozó felületén. Ezt a műveletet általában a gyárban elvégzik, de megismételhető például szektorméret-változtatás céljából (ún. Low-Level Format). A szektoroknak van egy láthatatlan fej- és láblécük, benne a szektor számával és a hibajavító kóddal. Logikai formázás: A felhasználás előkészítése. Két lépésből áll: 1) a (nyers) lemezterület elkülönített részekre szeletelése particionálás. 2) Az egyes partíciókon a szükséges adatszerkezetek felépítése a fájlrendszer létrehozása. Master Boot Record (MBR): A particionált merevlemez legelső szektora (az első lemez első sávjának első szektora). Egy rövid programot tartalmaz, amelyet a ROM-ba beépített rendszerindító rutin olvas be és futtat, ez a rövid program az operációs rendszer magját tartalmazza, amely tulajdonképpen elindítja a rendszert. Partíció: A lemez egy független szelete. Az alkalmazások és az operációs rendszer magasabb rétegei számára általában lemezegységhez hasonló eszközként látszanak (hasonló!). Az egyes partíciókat különböző 8

9 célokra lehet használni, például: nyers partíciók (adatbáziskezelőknek), virtuális memóriaterület (swap), fájlrendszer. Redundáns tömbök, kötetkezelő rendszerek. RAID fogalma: Redundant Array of Inexpensive/Independent Disks Az alapötlet: ha egy diszk átlagosan üzemórát (~11 évet) bír ki, akkor egy 100 diszkből álló rendszerben átlag 42 naponta kiesik egy! Erre megoldás, ha redundánsan tárolunk, és ezt rejtsük egy virtuális lemezegység mögé így új interfészre sem lesz szükségünk. A RAID szoftveresen és hardveresen is megvalósítható. Szoftver-RAID esetén az operációs rendszer valósítja meg, így partíciók felett is működhet, Harver-RAID esetén általában egész diszkeket kötünk össze, így az operációs rendszer szemszögéből egy szokásos lemezegység látszik. Az utóbbi drágább és hatékonyabb. RAID 0 (Striping Összefűzés): Több diszk tárterületét összefűzzük egy logikai diszkké. Ennek blokkjait általában szétosztjuk a fizikai diszkek szektorai között (striping). Blokknál nagyobb egységeket szoktunk szétosztani, de akár bitszintű szétosztás is lehetséges. Nincs redundancia az adatvesztés esélye nő! Szekvenciális adatkezelésre tökéletes (párhuzamosítás), de véletlen hozzáférésűhöz nem az igazi. RAID 1 (Mirroring Tükrözés): Minden adatot két független diszken tárolunk a tároló kapacitás a felére csökken. Az olvasási teljesítmény valószínűleg nő (melyik fej van közelebb az adott szektorhoz mind szekvenciális, mind véletlenszerű esetben jól jön), az írás ellenben valószínűleg csökken (mindkét diszkre ki kell írnunk szekvenciális/véletlenszerű esetben is lassít). A diszkhibából eredő adatvesztés esélye drasztikusan csökken. Az egyik legegyszerűbb és legdrágább megoldás (a CPU igényt nem növeljük, de 1GiB tároláshoz 2GiB háttértár kell). RAID 2 (ECC Erasure Correcting Code Megsemmisülést Javító Kód): A gépi memóriánál megszokott hibajavító kód használata, ehhez az adatbitek mellett néhány extra bitet is tárolunk. A bájt bitjeit és a hibajavító biteket különböző diszkeken tároljuk az egyik diszk meghibásodása esetén helyreállítható a hiányzó bit. A gyakorlatban ritkán használjuk, mert bonyolult algoritmus és hardveresen lassú. RAID 3 (Paritybits Paritásbitek): A memóriával ellentétben a diszkeknél tudjuk, hogy melyik romlott el nincs szükség hibajavító kódra, elég egy egyszerű paritásbitet tárolni (XOR). Előnyei: olcsó elég plusz egy diszk, a szekvenciális műveleteket gyorsítja (mint RAID 0), ellenben véletlen elérésűekhez ez sem az igazi. Hátrányai: magasabb CPU igény, az összes I/O műveletben az összes diszk részt vesz párhuzamosítás kevésbé lehetséges. 9

10 RAID 4: A RAID 3-hoz hasonló felépítésű, de itt a szektorokat is szétosztjuk az egyes diszkek között. Szekvenciális és véletlen elérésű műveletekhez is kiváló, de problémát okoz, hogy minden írásnál újra kell számolnunk a paritást (ámde azzal lehet trükközni: nem kell mindent újra beolvasni, elég a Hamming-távolságot megnézni a felülírt területen). Hátrány még, hogy a diszkek igénybevétele nem egyforma, valamint, hogy az adattároló diszkeket nem tudjuk párhuzamosan maximum 25%-nál jobban leterhelni (hisz akkor már a paritás-diszk 100%-on pörög). RAID 5: A RAID 4-hez hasonló felépítésű, de itt a paritás blokkokat az adatok közé keverjük (rotating parity körbeforgó paritás). Ennek köszönhetően a diszkek igénybevétele kiegyenlítődik. Az írások jobban párhuzamosíthatóak, de még mindig lassabbak az egyszerű tükrözésnél (plusz CPU igény is nagyobb). A gyakorlatban ez a legelterjedtebb. RAID 6: A RAID 5 kibővítése a paritásblokkok mellett tárolunk egy másik hibajavító kódot (pl.: oszlop paritásblokkja, Reed-Solomon kód, stb.), ezt is az adatok közé keverve. Két plusz diszket igényel, és a RAID 5-nél jelentősen nagyobb a CPU igénye. Az egyetlen RAID, ami két diszk kiesését is kibírja, és vissza is tudja állítani az adatokat, elvileg általánosítható lenne kettőnél több diszk esetére is, de a gyakorlatban nem éri meg. RAID 0+1 / RAID 1+0: A RAID 0 teljesítményét és a RAID 1 megbízhatóságát ötvözhetjük hibrid megoldásokkal. Szerencsés esetben ezek a tömbök több diszk kiesését is elviselik. A RAID 1+0 megbízhatóbb megoldás, mert egy diszk kiesése csak az adott tükrözött tömböt érinti, a rá épülő RAID 0-t nem. Mindkettő a RAID 1-hez hasonlóan drága megoldás. 10

11 Egyéb hibrid RAID-ek: Lehetőségünk van más RAID-ek hibridizációjára is. Például: a RAID 5-öt ötvözhetjük a RAID 1- gyel akár parciálisan is (egy adott diszkről készül tükrözés). RAID a gyakorlatban: RAID 0, RAID 1, RAID 5 és RAID 6, amiket használnak a gyakorlatban (illetve a RAID 0+1, RAID 1+0 megoldásokat). A komponens diszkek mérete meg kell, hogy egyezzen egymással, és új diszkek hozzáadása menet közben nem lehetséges, újra létre kell hoznunk az egész tömböt. Általában lehetőség van ún. készenléti diszkek definiálására, amelyeket a rendszer automatikusan üzembe állít meghibásodás esetén (és megkezdi az adatok helyreállítását). Ezen új diszk szinkronizációja időbe telik, ezalatt a tömb teljesítménye csökken. Szinkronizáció alatti újabb meghibásodás végzetes (kivéve RAID 6 esetén). Választási szempontok (bármelyik kettőt teljesíthetjük, de mindhármat nem): magas megbízhatóság (RAID 1, RAID 5, RAID 6, RAID 1+0, RAID 0+1) nagy teljesítmény (RAID 0, RAID 1, RAID 1+0, RAID 0+1) alacsony költség (RAID 0, RAID 5, RAID 6) Ezt minden rendszernél el kell döntenünk, hogy melyik a két fő szempont. Azt is számításba kell vennünk, hogy a RAID-ek sem nyújtanak védelmet minden hibalehetőséggel szemben (emberi tévedések, programhibák, váratlan leállások, túlfeszültség, természeti katasztrófák, stb.). Kötetkezelő rendszer (Volume Manager): A fejlett operációs rendszerek megkönnyítik a hibatűrő logikai diszkek létrehozását és üzemeltetését. A kötetkezelő rendszertől a partíciókhoz hasonló, de rugalmasan átméretezhető, hibatűrő logikai tárterületek (ún. kötetek) igényelhetőek, ezek alatt a fizikai partíciók tárterületével a kötetkezelő automatikusan gazdálkodik. 11

12 Állományrendszerek szolgáltatásai és megvalósításuk. Absztrakció: A rögzített méretű blokkok lineáris tömbje jó tárolásra, de kezeléshez túlságosan alacsony szintű. Megoldás: absztrakciós szintek bevezetése (fájlok, könyvtárak, fájlrendszerek). Fájlrendszer: Az adatállományok egy tárolási és elrendezési módszere a rendelkezésre álló diszken. Teljesen absztrakt adatszerkezet (és hozzá tartozó műveletek) a lemez blokkjainak kiosztására. Általában a fájlokat könyvtárakba rendezhetjük, és lemezterület nélkül is létezhet fájlrendszer (pl.: hálózati fájlrendszerek, virtuális fájlrendszerek, stb.). Az itt megoldandó problémák hasonlítanak a memóriakezelés feladataira (ergo az ott tárgyalt algoritmusok First/Next/Best/Worst Fit itt is alkalmazhatóak), a rögzített méretű blokkok a lapokra emlékeztetnek, de a diszk fizikai sajátosságai mégis alapvetően más megoldásokhoz vezetnek. Fájl: A permanens információtárolás egy egysége. Legegyszerűbben: olyan bitsorozat, amely a rendszer újraindítása során sem vész el. Logikailag lehet: bájtsorozat, fix méretű rekordok sorozata, változó méretű rekordok sorozata, egyéb (pl.: szegmensekre osztott), stb. Fizikailag egyáltalán nem biztos, hogy egymás utáni blokkokban tárolódik (külső töredezés), és az utolsó blokk általában töredékblokk. Ha a rekordméret nem egész osztója a blokkméretnek, akkor ún. belső töredezettség lép fel nem célszerű, ha a rekord túlnyúlik a blokkhatáron; az első rekordokat érdemes levegősen elhelyezni, ha sok a beszúrás (hogy később legyen hova); az utolsó töredékblokk is egyfajta belső töredezettség. Fájl meta-adatai: A fájlok a tulajdonképpeni adatok kívül meta-adatokat (attribútum) is tárolnak, pl.: a fájl neve, azonosítója, típusa, létrehozója, elhelyezkedése, mérete, tulajdonságai, elérési jogosultságok, időbélyegzők, stb. Ezeket a meta-adatokat a fájl tartalmától elkülönítve, önálló fájlleíró blokkokban tároljuk. Több bitsorozat egy fájlban: Egyes rendszereken a fájlok egymástól elkülönített bitsorozatokra bonthatóak (pl.: Apple Macintosh erőforrás- és adatszegmens: erőforrásszegmensben a felhasználó által módosítható segédinformációk; Microsoft NTFS fájlnév:attribútumok felhasználás például képfájlok előnézetének tárolására). Fájlok elérése: A fájlokat elérhetjük szekvenciálisan és közvetlenül (véletlenszerűen). Az elérés lehet relatív (a rekord fájlon belüli sorszáma alapján), vagy indexelt (a rekord tartalma, mint kulcsértéke alapján egy és többszintű rendezett indexelés vagy akár B-fák, hasítótáblák, stb.). A fájl típusa közli, hogy a fájl tartalma hogyan értelmezhető (Macintosh: explicit metaattribútummal; Window: kiterjesztéssel a fájlnévben; Unix: a fájlban elhelyezett speciális kódok). Fájlműveletek: Új, üres fájl létrehozása; létező fájl törlése; írás (átírás, hozzáírás, beszúrás); olvasás (szekvenciális vagy közvetlen); újrapozicionálás (olvasás közben); adott pont utáni törlés (nyesés truncate); meta-adatok lekérdezése/módosítása (pl.: átnevezés); egyebek (zárolás, memóriába képezés, stb.). Ezen műveletek hatékony implementációja a fájlrendszer feladata. 12

13 Könyvtár: A fájlrendszeren tárolt fájlok jegyzékeit könyvtáraknak hívjuk. Könyvtár könyvtár(ak)at is tartalmazhat. Operációs rendszerenként eltérő, hogy milyen szerkezetben, az általános jellemzők: tetszőleges könyvtárnak lehetnek alkönyvtárai a gyökérkönyvtárnak nincs szülője általában fa szerkezetű (de lehet körmentes gráf, vagy akár általános gráf ez szimulálható is pl.: szimbolikus linkekkel) az aktuális könyvtárban dolgozunk (a referált fájlok elérési útjához automatikusan hozzáadódik az aktuális munkakönyvtár path-ja) az elérési út általában a fájlnév részeként kezelendő (amire megkötések is lehetnek, pl.: Windows XP esetén a path maximum 255 karakter hosszú lehet) ahány rendszer, annyiféle hivatkozási konvenció Könyvtár meta-adatai: Neve, hossza, tulajdonosa, elérési jogok, időbélyegzők, stb. Könyvtárműveletek: Új, üres könyvtár létrehozása; létező könyvtár törlése; listázás; bejárás; keresés; meta-adatok lekérdezése, módosítása (pl.: átnevezés); stb. Fájlhivatkozás (szimbolikus link): Egy másik bejegyzésre hivatkozó speciális bejegyzés (automatikus dereferálás az operációs rendszer által). Támogatás: Egy operációs rendszer általában nem csak egyféle fájlrendszert támogat. Más fájlrendszer való merevlemezekre, más CD/DVD/BD-kre, más PenDriver-okra (szélsőséges példa: Linux 2.6 több, mint 50 fájlrendszer-típus). VFS (Virtual Filesystem Switch Virtuális Fájlrendszer Kapcsoló): az alkalmazások I/O műveleteiről eldönteni, hogy melyik konkrét implementációnak kell továbbadni. Csatolás: A fájlrendszert használatba vétel előtt csatolni (mount) kell, ezalatt értjük a superblock beolvasását, és a fájlrendszertáblába az új sor felvételét. A csatolás lehet automatikus (pl.: hordozható háttértárak), automatikus hivatkozás után (pl.: hálózati fájlrendszerek), rendszergazdai közreműködésre. A csatolás lehet teljesen más névtérbe (VMS, Windows), vagy az adott könyvtárszerkezetbe (Unix/Linux). Blokkfoglalási módszerek, szabad tárterület nyilvántartása, naplózás. Blokkfoglalás: A fájlok tartalmát adatblokkokban tároljuk, nyilván kell tartanunk, hogy melyik blokk melyik fájlhoz tartozik (és milyen sorrendben), valamint tudnunk kell új blokkot adni a fájlhoz. Blokkfoglalási módszerek: 1. Folytonos: a fájlok blokkjait tároljuk egy darab folytonos diszkterületen. Hátrányai: elaprózódás, a lassan növő fájloknál belső töredezés, a fájlméretek statikusak. Használata: Read-Only háttértárakon (CD, DVD, stb.); nagy I/O igényű gépeken (pl.: mianframe-ek). 13

14 2. Extens alapú: megengedjük, hogy fájlméret növelése esetén az új tárterület a diszk egy másik összefüggő területe legyen. Ezt nyilván kell tartanunk, az extensek mérete általában egységes, melyet a fájl létrehozásakor adunk meg. Hátrányai: nagy extensméret jelentős belső töredezettség; dinamikus extensméret külső töredezettség. 3. Láncolt listás: minden adatblokk végére tegyük be a következő adatblokk számát. Hátránya: csak szekvenciális I/O műveletek esetén elfogadható; a használható tárkapacitás %-ban mérhetően csökken; a blokkmutatók elromlása esetén súlyos adatvesztés. Javítása: fürtözés (clustering) több blokkot összefogunk, javítható a viselkedés, erősödik a belső töredezettség; jellemző a blokkmutatók kigyűjtése egy külön táblázatba (pl.: FAT). 4. Indexelt: a fájl adatblokkjainak sorszámát soroljuk fel egy külön e célra fenntartott indexblokkban (minden fájlhoz külön indexblokk). Ha betelik az indexblokk láncoljunk egy másikat hozzá VAGY második szintű indexblokkot definiálunk. Hatékony és gazdaságos elterjedt (pl.: Linux ext2). Szabad terület nyilvántartása: Tudnunk kell, hogy hol van szabad hely. Ehhez különböző megoldások vannak: 1. Bittérkép: a tárterület egy elkülönített részén minden blokkhoz egy bitet rendelünk (ha a bit értéke 1, akkor a blokk szabad). Hatékonyabbá tehető, ha a térkép a memóriában is megvan. Népszerű, viszonylag olcsó megoldás, ügyes algoritmusokkal elkerülhető a fájltöredezés. 2. Láncolt lista: a szabad blokkokat láncolt listába fűzzük (FAT ezt használja), viszont nem teszi lehetővé a fájltöredezettség elkerülését. 3. Kigyűjtés: az első szabad blokkban felsoroljuk az összes többit, ha betelik megtoldjuk a következővel; előnye, hogy nem igényel extra területet, gyorsan lehet egyszerre sok szabad blokkot lefoglalni, ellenben a fájltöredezettséget itt is nehézkes kivédeni. Naplózás: Egy adott fájlrendszer-művelet gyakran egyből több I/O műveletet igényel. Mi történik, ha e közben váratlan hiba (pl.: áramszünet) lép fel? Alapesetben ilyenkor az egész fájlrendszert meg kell vizsgálnunk ez gyakran órákig eltart, és gyakran emberi közbeavatkozás nélkül nem is lehetséges a helyreállítás. Ötlet: legyen egy adott fájlrendszer-művelet egy tranzakció, és készítsünk az adatbázis-kezelő rendszereknél megszokott redo log -ot. A napló a fájlrendszer egy arra kijelölt helyén van, és egy speciális rendszerfolyamat a háttérben folyamatosan átvezeti az elvégzett tranzakciók műveleteit a naplóból a tulajdonképpeni fájlrendszerre. Még hatékonyabb lehet, ha a naplót külön diszken vezetjük seek latency csökken; a napló diszkjének meghibásodásakor újra kell készítenünk a napklót és ellenőrizni az adattároló lemezt. Naplózáshoz szinkronizált I/O-t kell használni (synchronous I/O), mert ha a firmware szabadon átrendezheti az I/O műveleteket, akkor az üzembiztonság elvész. Megfigyelhető, hogy a naplózás némileg rontja a teljesítményt (hiszen a naplót is vezetni kell), de az üzembiztonság általában fontosabb szempont, mint a teljesítmény. Viszont itt is lehet hatékonyságnövelést végrehajtani, például: a módosítások nem kerülnek azonnal átvezetésre ha közben jön egy újabb változás, akkor minek? (ideiglenes fájlt szinte azonnal töröltük is). 14