Opercis Rendszerek II 12 elads 2007 prilis 23

Operációs Rendszerek II. 12. előadás 2007. április 23.

Fájlok, fájlrendszerek • Felhasználói szempontból az operációs rendszer (egyik) legfontosabb része – Ezzel közvetlen „találkozik” – A fájlok tárolása, hozzáférés alapvető – Teljesítmény szempontból kritikus

Alapvető elvárások • Hosszú távú tárolás – A fájlokat másodlagos tárolón (tipikusan merevlemezen) tároljuk – A fájlok tartalma a felhasználó kilépése, a gép kikapcsolását követően is megmarad • Megoszthatóság – Ugyanazt az adathalmazt több program is elérhesse – a fájlok egyértelmű azonosítása alapvető – Amennyiben igényelt, a fájlokat több felhasználó is elérhesse • Strukturáltság – A fájlok tartalmát (adatokat) jól ismert struktúrába kell szervezni – A fájlok között is célszerű struktúrát definiálni (sok fájl, átláthatóság)

Tipikus fájl műveletek • Általános modell – Létrehozás – Törlés – Megnyitás – Lezárás – Olvasás – Írás • Az egyes konkrét implementációk további műveleteket is definiálhatnak

Fájl struktúrák • Struktúra-elemek – Mező, alapelem – Rekord, összetartozó mezők gyűjteménye – Fájl, összetartozó rekordok – Adatbázis, összetartozó fájlok • Mai rendszerekben a struktúra meglehetősen egyszerű, az összetett(ebb) adatstruktúrák kezelését alkalmazás szintű komponensekre bízzák

Fájl menedzsment rendszer elvárások • Felhasználók (és alkalmazások) adattárolási, adatkezelési igényeinek kielégítése • Tárolt adatok validitásának biztosítása • Teljesítmény optimalizálás rendszer (globális) és felhasználói szempontból egyaránt • Különféle tároló eszközök támogatása • Adatvesztés kockázatának minimalizálása • Szabványos (programozói) interfész biztosítása • Többfelhasználós működés támogatása

Fájlrendszer architektúra

Rétegek • Device driver: kommunikáció a különféle hardver elemekkel (eszközfüggő) • Basic FS (physical I/O): alacsony (blokk) szintű műveletek • Basic I/O supervisor: I/O sorbaállítás, ütemezés • Logical I/O: magas szintű file műveletek • File szervezés: NEM Unix/Win világban – – – Pile („struktúrálatlan”, ahogy jön) Szekvenciális (rekord alapú) Indexelt szekvenciális (rekord alapú) Indexelt (rekord alapú) Direct (hash) fájlok (rekord alapú)

Könyvtárak • A legtöbb rendszerben a fájlokat valamiféle struktúrába szervezzük – A könyvtár tipikusan egy fájl, ami a benne található fájlok adatait tartalmazza – A fájlokról tárolt adatok köre eltérő, de tipikusan az alábbiakat kell tárolni • • Alapinformációk (név, típus, szervezés) Elhelyezkedési információk (kezdőpont, méret, részek) Hozzáférés vezérlési információk (jogosultság) Használati információk (időpontok, esetleg userek)

Könyvtárak • Alapvető könyvtár műveletek – – – Keresés (fájl keresése) Fájl létrehozása Fájl törlése Könyvtár tartalom listázása Könyvtárban tárolt fájl-jellemzők aktualizálása • Megoldások – – Egyszerű lista Kétszintű (felhasználónkénti) Fastruktúra (szinte egyeduralkodó) Egyéb (pl. z/OS)

Fájlhozzáférések • Többfelhasználós rendszerben kontroll szükséges! • Jogosultsági szintek: – – – – Semmi (nem is tud róla) Tudhat róla Végrehajtás Olvasás Hozzáfűzés Módosítás Jogosultság módosítás Törlés hozzáférés

Fájlhozzáférések • Hozzáférési szintek – Egyedi felhasználók – Csoportok – Mindenki • Jogosultsági szintek – Sokszor egyszerűbb és/vagy más mint a fent felsorolt • a jogosultsági metódusoktól is modell függ a fájl/könyvtár kezelési • Megoldás – Fix jogosultsági struktúra (pl. tulajdonos – csoport – egyebek) – ACL-ek

Párhuzamos elérés • Multiprogramozott rendszerekben egy időben egy fájlhoz több folyamat is próbál(hat) hozzáférni – Ha mind csak olvasni próbálja, nincs gond – Ha csak egy is írni próbál, lehetnek problémák • A fájlokhoz való egyidejű hozzáférés korlátozása a zárolás. • Zárolási szempontok – Zárolás módja • Csak olvasás: mindenki csak olvashatja a fájlt (írást nem enged) • Teljes: egy felhasználó (folyamat) módosíthat, a többi nem férhet hozzá – Zárolás szintje • Teljes fájl • Fájl egy része

Másodlagos tároló menedzsment tervezési tere • Fájl foglalása – Előzetes foglalás – Dinamikus foglalás • Foglalási egység – Összefüggő – Blokk alapú • Fájl foglalási módszerek (blokkos) – Folyamatos foglalás – Láncolt foglalás (minden blokk külön) – Indexelt foglalás (minden blokk külön) • Szabad hely nyilvántartása – – Bit tábla használata Láncolás Indexelés Szabad blokkok listája (külön területen, a diszken tárolva)

Másodlagos tároló menedzsment tervezési tere • Fájl foglalása – Előzetes foglalás: a létrehozáskor lefoglaljuk • Fix, létrehozáskor megadandó fájlméret • Mivel a fájlok mérete legtöbbször nehezen becsülhető, tipikus a „túlfoglalás” – Dinamikus foglalás • A fájl mérete futási időben változhat • Foglalási egység – változó hosszúságú, összefüggő • nagyon jó teljesítmény • módosítás és felszabadítás problémás – blokk alapú: fix méretű (kicsi) blokkokból foglalunk. • Bonyolultabb nyilvántartás, rosszabb teljesítmény • könnyen módosítható és újrahasználható • Foglalási algoritmusok – First fit (első megfelelő blokk keresése) – Best fit (a legjobban illeszkedő blokk keresése) – Nearest fit (legközelebbi blokk keresése)

Másodlagos tároló menedzsment tervezési tere • Fájl foglalási módszerek (blokkos) – Folyamatos foglalás • • Összefüggő területet foglal, előzetes foglalással Nagyon jó szekvenciális I/O teljesítmény Kellő méretű helyet lefoglalni sokszor nehéz Külső elaprózódás és tömörítés problémája jelentkezik – Láncolt foglalás • minden blokk külön foglalandó, a blokkokból láncot képzünk • a fájlban való mozgás a láncon keresztül történik • a fájlok széttöredezhetnek, ez jelentős teljesítmény probléma lehet – Indexelt foglalás • minden blokk külön foglalandó, a blokkokból index-táblát építünk • Az index-tábla kezelése kérdéseket vet fel (lásd Unix FS-ek)

Másodlagos tároló menedzsment tervezési tere • Szabad hely nyilvántartása – Bit tábla használata • Bitvektor, a diszk minden blokkjához egy bitet rendelünk, a bit értéke mutatja az adott blokk foglaltságát • Könnyű benne összefüggő blokkokat keresni • A tábla meglehetősen nagy lehet, ez problémákat vet fel – Diszk: 16 Gbyte, Blokkméret: 512 byte – tábla: 4 Mbyte – Memóriában legyen vagy diszken? – Mennyi CPU ciklus végignézni a teljes táblát? – Láncolás • Láncolt lista a szabad blokkokról – Indexelés • Indextábla a szabad blokkokról – Szabad blokkok listája • külön területen, a diszken tárolva • Az lista elejét a memóriába töltjük és ezt használjuk (ha elfogy, újra beolvasunk egy részt a diszkről)

Klasszikus Unix fájlrendszer • Fájlok a felhasználók szempontjából – egyedi névvel (nevekkel) rendelkező (régen 14, ma 255 hosszú) – bájtfolyamok • Belső ábrázolás ettől lényegesen eltér – Adattárolás tip. blokkorientált eszközön, tárolási mód is ehhez igazodik – A fájlokat adatblokkokban tároljuk, a fájlokról tárolt információk kezelésének alapja pedig az inode (index-node) - amely az i-node táblázat egy bejegyzése. Az inode tartalmazza • • fájlokhoz rendelt lemezterületek azonosítóit (blokk sorszámait), fájl tulajdonosát, elérési jogokat, létrehozási, címzési dátumot nevet nem tartalmaz – Minden fájlhoz egyetlen inode tartozik, azonban egy inode-hoz tartozhat több fájlnév is - ekkor ugyanarra a fizikai fájlra több helyről (több néven) hivatkozunk. Minden inode-hoz rendelt fájlnevet linknek nevezünk.

Klasszikus Unix fájlrendszer • Az inode-fájlnév összerendeléseket a - szintén fájlként létező - könyvtár-fájlok tartalmazzák – Könyvtár fájl tartalma: a könyvtárban található fájlok és a hozzájuk tartozó i-node értékek listája – Alkönyvtárak: ezek is fájlok (tehát ugyanúgy név és inode pár, de a típusok ‘könyvtár’) – Minden könyvtárfájl tartalmaz egy '. ' és egy '. . ' nevű fájlt (‘könyvtár’ típus). • a '. ' fájl az aktuális könyvtárra mutató link • a '. . ' a szülő könyvtárra mutat • Ez a két fájl (link) teszi lehetővé a relatív mozgást a könyvtárstruktúrában

Fájlok tárolása • Fájlok tárolása nem (feltétlenül) egymást követő blokkokban történik, a fájlhoz tartozó összes blokk címét tárolni kell (nem elég csak az első blokk címe). • A fájlokhoz tartozó lemezterületek azonosítása a UNIX rendszerben az i-node bejegyzésen belül történik. – a - FAT stílusú - láncolt listánál biztonságosabb megoldás – mivel az i-node mérete (és ezzel együtt a bejegyzésen belül tárolt lemezhivatkozások száma) kötött, szembe kell néznünk a változó fájlméret okozta problémákkal. • Ha egy i-node bejegyzésen belül „sok” lemezhivatkozási címet helyezünk el, sok (kis méretű) fájl esetén a bejegyzések nagy része kihasználatlan marad • Szinte biztos, hogy felmerül az igény a kezelhető méretnél nagyobb méretű fájl kezelésére is. – A UNIX a következő módszert használja: minden i-node bejegyzés kötött számú rekord-hivatkozást tartalmaz, azonban ezen bejegyzések egy része nem adatterületre, hanem lemezterület-leíró rekordra mutat amely ismét tartalmazhat hivatkozást további terület(ek)re.

Fájl-blokkok címeinek meghatározása

Fájl-blokkok címeinek meghatározása

Fájl-blokkok címeinek meghatározása

Fájlrendszerek mérete (System V) • 1024 bájtos blokkméret, az i-node 13 bejegyzést tartalmaz – ebből 10 adatterületre mutat – 3 pedig un. indirekt rekordokra – az i-noden belül max. 10 kbájt méretű fájl adatai tárolhatóak • 32 bites blokkcím, egy indirekt rekord 256 rekordcímet tartalmaz – Az első indirekt rekord 256 adatterület címét tartalmazza, – a második 256 lemezterület-leíró rekord címet (dupla indirekció), – a harmadik pedig már tripla indirekció. • Méretek – ezzel a módszerrel 16 Gbájtnál nagyobb fájlok is kezelhetőek – A 32 bites rekordcímek miatt a legnagyobb fájlméret 4 gigabájt • Értékelés – 1984 -es vizsgálat szerint az i-noden belül tárolható 10 kbájtos fájllimit sok esetben elegendő (19. 978 mintafájl 85%-a 8 Kbájtnál kisebb volt). – A mai rendszerekben a 4 giga kevés, de a blokkméret sem 1 k…

File hivatkozások (System V) • A felhasználó a fájlokra nevével hivatkozik • A rendszer (a könyvtárfájlokon keresztül) megkeresi a fájlnévhez tartozó inode-t – ebből megállapítja a hozzáférés jogosságát – és a fájl elhelyezkedését a háttértárolón • Új fájl létrehozásakor a rendszer a fájlhoz egy nem használt inode-t rendel – Az inode-kat a rendszer a fájlrendszer részeként tárolja – a megnyitott fájlok inode-it a memóriában tárolja.

File hivatkozások (System V) • A kernel az inode-táblán (nyitott fájlok inode-i) túl két további táblát is tartalmaz – a fájl táblát – felhasználói fájlleíró táblát, ezt minden folyamathoz külön létrehozza a rendszer • Ha egy folyamat megnyit vagy létrehoz egy fájlt a kernel mindhárom táblában létrehoz bejegyzést (kivétel, ha a fájlt már más is megnyitotta) – A fájl tábla - többek között - a fájlmutató helyét tartalmazza a fájlban – A felhasználói fájlleíró tábla a folyamat rendelt megnyitott fájlok listáját tartalmazza. • Fájlmegnyitás (létrehozás) esetén a kernel egy ún. fájlleírót ad vissza - ez a leíró a felhasználói fájlleíró táblának egy helyét azonosítja.

Sys V FS • A háttértárak kezeléséhez a UNIX minden (fizikai) egységen létrehoz egy vagy több fájlrendszert. – A UNIX számára minden fájlrendszer egy különálló logikai egységet jelent. – A fájlrendszer logikai blokkok (rekordok) egymásutánjából áll. – A blokkok mérete rendszerfüggő, általában 512 byte szorozva kettő (kis) hatványával, a blokkméret egy fájlrendszeren belül állandó. – A logikai blokk jelentőssége a következő: minden kernel-háttértároló közötti adatcsere esetén a blokkméret egész számsorosa áramlik - a legkisebb adatátviteli egység a (logikai) blokk • Ez akkor is igaz, ha csak néhány bájtot olvasok vagy írok! – A logikai blokk méretétől az adatátvitel gyorsasága, és a háttértároló kihasználtsága függ - ezek azonban egymásnak ellentmondó szempontok (míg a a System V esetén egy blokk egy és csakis egy fájlhoz tartozhat, a 4. 2 BSD már megengedi a blokk felosztását)

Sys V FS • A fájlrendszer felépítése a következő: – a boot block a fájlrendszer legelső blokkja, és a rendszer indításakor végrehajtandó, rendszertöltést indító kódot tartalmazza – a super block írja le a fájlrendszert • hány blokkból áll, hány fájlt tud tárolni • hol vannak szabad i-nodek (ez a lista nem teljes) • hol találhatóak szabad blokkok (teljes lista, de részben az adatterületen van) – inode lista - az inode-kat tartalmazó blokk(ok), • a terület méretét a rendszergazda határozza meg generáláskor (statikus) • Ez határozza meg a létrehozható fájlok számának maximumát – adat block-ok • Alapvetően a fájlok adattartalma (blokkok) található itt, de vannak kivételek – Könyvtárfájlok – Szabad blokkok listája • minden egyes blokk egy és csakis egy fájlhoz tartozhat

Élet a Sys V után • BSD FFS – a Sys V sok korlátját orvosolja • Speciális fájlrendszerek (proc, tmpfs) • További fejlesztések (pl. naplózott fájlrendszerek) • Merőben más út: z/OS operációs rendszer

Konkurencia • Csak nagyon röviden • Szituációk – Folyamatok közötti „direkt” együttműködés – Folyamatok között „akaratlanul” kialakuló versenyhelyzetek • Problémák, megoldási lehetőségek

Folyamatok együttműködése • A folyamatoknak sokszor szükségük van arra, hogy más folyamatokkal kommunikáljanak – Folyamatok működésükhöz más folyamattól várnak adatot • Adatok átadása (egyik folyamat a másiknak) • Adatok megosztása folyamatok között – Közös erőforrásokért versengő folyamatok szinkronizációja – Különböző folyamatok által végzett műveletek megfelelő sorrendben történő végrehajtásának biztosítása • Sok operációs rendszer lehetővé teszi, hogy az együtt dolgozó folyamatok megosszanak bizonyos erőforrásokat egymás között – versenyhelyzet alakulhat ki

Versenyhelyzetek - alapprobléma • Klasszikus probléma, egy print spooler rendszer – Ha egy folyamat ki szeretne nyomtatni egy fájlt, akkor a fájl nevét elhelyezi a print spooler következő üres sorában. • Spooler betelésével most nem foglalkozunk (kellően nagy) – A spooler bejegyzéseit természetes számokkal azonosítjuk (sorszám) – A rendszer továbbá két osztott változót használ • out változó a következő nyomtatandó fájl helyét adja meg • in változó a következő szabad bejegyzés helyét mutatja. • Az alábbi szituációban kíván az A és B folyamat többé-kevésbé egyszerre új bejegyzést átadni a rendszernek.

Versenyhelyzet folyt. worst case scenario • ‘A’ folyamat – Kiolvassa az in változó értékét (6), majd eltárolja egy belső változójában. – Mielőtt megnövelhetné az in változó értékét, az ütemező átadja a vezérlést a B folyamatnak • ‘B’ folyamat – – Szintén 6 -ot olvas ki az in változóból Az általa nyomtatni kívánt fájl nevét eltárolja a spooler 6 -os sorában Utána megnöveli in értékét is Vezérlés visszakerül az A folyamathoz • ‘A’ folyamat – A sor számát nem az in változóból veszi, hanem a belső változójából, – A folyamat is a 6 -es sorba fogja elhelyezni a fájlnevet

Versenyhelyzet folytatás, megállapítások • A fenti problémához hasonló problémákat, ahol több folyamat szeretne közös adatokat használni, és a futás eredménye a folyamatok végrehajtásának egymáshoz képesti ütemezésétől is függ versenyhelyzetnek nevezzük. • Az átmeneti változó az előző példában a processzor akkumulátor regisztere is lehet, tehát még egy gépi kódú program sem lenne elegendő a probléma feloldásához

Versenyhelyzet kialakulásának megakadályozása • Megoldás az, ha biztosítani tudjuk, hogy az osztott erőforrásokat egy időben csak egy folyamat olvashassa ill. módosíthassa — tehát kizárólagos hozzáférésre van szükségünk. – A kizárólagos hozzáférés biztosítása azonban nem csak egyetlen gépi utasítás erejéig szükséges, hanem egy kódrészlet végrehajtása alatt. – A programok azon részét, amelynek megszakított végrehajtása problémákat okozhat kritikus régiónak hívjuk. – Ha el tudjuk érni, hogy egyszerre csak egy folyamat hajtsa végre a kritikus régiójához tartozó kódrész utasításait, elkerülhetjük a versenyhelyzeteket. • A teljes megoldáshoz négy feltétel egyidejű teljesülése szükséges: – Egy időben csak egy folyamat futtathat a kritikus régiójához tartozó kódot. – A processzorok sebessége vagy száma nem befolyásolhatja a működés végeredményét. – A kritikus szekcióján kívül futó program nem blokkolhatja más folyamatok végrehajtását – Egyetlen folyamatnak sem kell örökre várakoznia, hogy végrehajthassa a kritikus szekcióhoz tartozó utasításait.

Kizárólagos hozzáférés megvalósítása (alapok) • Megszakítások tiltása – A legegyszerűbb megoldást jelenti, ha a kritikus szekciójába belépő folyamat által végrehajtott első utasítás a megszakítások tiltása. • Ha a megszakításokat letiltjuk, a rendszeróra megszakítása sem jut érvényre, így az ütemező sem jut érvényre. • Ez a megoldás a gyakorlatban használhatatlan, ugyanis egyetlen hibás felhasználói folyamat a teljes rendszert lebénítaná. Az operációs rendszer kódján belül azonban sokszor használják ezt a fajta megoldást (bár mára jelentőssége erősen lecsökkent). • Üzenettovábbítás – Az üzenettovábbítás a folyamatok közötti kommunikáció egy igen elterjedt módja. Két primitív műveletet használ, a SEND művelet segítségével egy üzenetet továbbíthatunk, míg a RECEIVE művelet üzenet vételét célozza.

Kizárólagos hozzáférés megvalósítása (alapok) • Szemaforok – A szemaforok elméletét E. W. Dijkstra dolgozta ki 1965 -ben – A megoldás lényege egy számláló változó, amelyet két művelet segítségével változtathatunk • A Down művelet eggyel csökkenti a számláló értékét. Ha a számláló értéke nulla volt, akkor a művelet mindaddig nem tér vissza, amíg a számláló értékét egy másik művelet nem növeli meg egyel. Ebben az esetben már a csökkentés végrehajtható • Az Up művelet a számláló értékét egyel növeli, és ha az érték előzőleg nulla volt, akkor egy várakozó Down műveletet „felébreszt” – A megoldás leglényegesebb eleme az, hogy az Up és a Down műveletek atomiak, tehát végrehajtásuk nem szakítható meg • A mai processzorok többsége már rendelkezik olyan gépi kódú utasítással ami lehetővé teszi a fenti műveletek atomi szintű megvalósítását – A szemaforokat a kizárólagos hozzáférés megvalósításán túl szinkronizációs célokra is felhasználhatjuk (pl. jelezzük, hogy egy puffer megtelt)

Folyamatok viszonya • Folyamatok közötti viszony szintjei – Folyamatoknak nincs tudomásuk egymásról – Folyamatoknak indirekt módon tudomásuk van egymásról – Folyamatok tudatosan együttműködnek

Folyamatok viszonya • Folyamatok közötti viszony szintjei – Folyamatoknak nincs tudomásuk egymásról • Egymástól teljesen független folyamatok (pl. multiprogramozott környezetben) • Az erőforrásokért folyó küzdelem miatt felléphet verseny szituáció, ezt OS szinten kezelni kell! – Folyamatoknak indirekt módon tudomásuk van egymásról – Folyamatok tudatosan együttműködnek

Folyamatok viszonya • Folyamatok közötti viszony szintjei – Folyamatoknak nincs tudomásuk egymásról – Folyamatoknak indirekt módon tudomásuk van egymásról • A folyamatok közös objektumokon (pl. I/O puffer) osztoznak • A közös objektumhoz való hozzáférés együttműködést igényel – Folyamatok tudatosan együttműködnek

Folyamatok viszonya • Folyamatok közötti viszony szintjei – Folyamatoknak nincs tudomásuk egymásról – Folyamatoknak indirekt módon tudomásuk van egymásról – Folyamatok tudatosan együttműködnek • A folyamatok feladatuk kapcsán működnek együtt (tudatos tervezési döntés következményeképpen)

További fogalmak • Holtpont (deadlock) – Folyamatok permanens blokkolódása – Elkerülésére nincsen általánosan jó megoldás • Kiéheztetés (starvation) – Valamely folyamat nem jut hozzá az általa igényelt erőforráshoz – Megfelelő (igazságos) erőforrás ütemezési algoritmusokkal kivédhető