Operációs Rendszerek II.

1. Operációs Rendszerek II. 13. előadás 2007. május 7.

2. 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

3. 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

4. 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.

5. 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

6. 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

7. 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.

8. 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.

9. 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)

10. 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

11. 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

12. 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

13. 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)

14. 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ő

15. A közelmúlt (90-es évek) Unix fájlrendszerei • Főbb mozzanatok • Fájlrendszer interfész és keretrendszer változásai, több fájlrendszer egyidejű támogatása • Többféle fájlrendszer megjelenése  • Szolgáltatások (pl. hosszú fájlnevek) • Méret (fájlrendszer, fájlok) • Teljesítmény • Megbízhatóság • Speciális funkciók (pl. tmp terület)

16. Fájlrendszer keretek • Fájlrendszer interfész (amely meghatározza az alapvető /rendszerközeli kódból hívható/ műveleteket) • hosszú ideje viszonylag stabilnak tekinthető • Újabb funkciók megjelentek, de cél volt a kompatibilitás megőrzése • A fájl keretrendszer az idők során jelentősen átalakult • Leglátványosabb: több fájlrendszer támogatása • Megoldás: vnode/vfs interfész

17. Több fájlrendszer – a kezdetek • Többféle fájlrendszer használatának igényére nem volt megoldás (a kernel csak egyet támogatott) • s5fs és/vagy FFS • DOS (pl. Floppy-k) • Speciális fájlrendszerek • Az 1980-as években a kommunikációs hálózatok elterjedésével a fájlmegosztás igénye is előtérbe került, egyebek mellett a transzparens hozzáférést kínáló Sun által fejlesztett NFS • NFS használata esetén a felhasználó ugyanolyan módon láthatja a helyi fájlokat, mint a távoli gépen lévőket • Az NFS megoldáshoz a Sun teljesen átalakította a fájl keretrendszert, később a megoldás (vnode/vfs) de facto szabvány lett (az SVR4 részévé is vált) • Az NFS is az…

18. A vnode/vfs architektúra • Tervezési szempontok • Többféle fájlrendszer egyidejű (Unix és nem Unix – pl. MS-DOS) támogatása • Különféle fájlrendszereket tartalmazó diszk partíciók csatolása (mount) után létrejövő kép konzisztens, a felhasználónak nem kell törődnie a különféle fájlrendszerek sajátosságaival • Fájlok (távoli) megosztásának támogatása • Saját fájlrendszerek típusok létrehozásának lehetősége

19. vnode/vfs koncepció • Objektum szemléletű megközelítés: • Vnode: a fájlok absztrakciója, a • Vfs: pedig fájlrendszeré a Unix kernelben • Absztrakt alaposztályok, minden tényleges fájlrendszer-implementáció ősei • Az osztályok adatelemei és metódusai virtualizáltak, a funkciók két szintre oszthatók • alacsony szintű funkciók (pl. open, read) – ezeket egyes fájlrendszer-implementációk implementálnak • magas szintű „utility” funkciók – alacsony szintű funkcióra épülő funkciók, ezeket tipikusan a kernel egyéb részei használják

20. Fájlrendszer Implementációs elvárások • Minden művelet végrehajtása a hívó folyamat nevében történik, a végrehajtás alatt a hívó blokkolódik/hat • Bizonyos műveletek kizárólagos fájl hozzáférést igényelnek – ezek struktúrák zárolását igényelhetik • Az interfésznek állapotmentensnek kell lennie, globális változókra nem támaszkodhat • Reentráns interfész szükséges, ez tiltja a globális változók használatát • Globális erőforrások (pl. buffer cache) használata megengedett • Támogatnia kell a távoli fájlelérést szerver oldalát • Fix méretű, statikus táblák használata nem lehetséges

21. Fájlrendszerek • SVR4 rendszerben támogatott fájlrendszerek • System V FS (s5fs) az „eredeti” Unix fájlrendszer • Berkeley Fast Filesystem (FFS, most ufs) • Veritas Journaling Filesystem (VxFS) • Eszközmeghajtók fájlrendszere, specfs • Hálózati fájlrendszer, NFS • Process fájlrendszer, /proc • Boot fájlrendszer, bfs • További implemetációk • MS-DOS FAT (pl. Solaris esetén) • CD (pl. ISO 9660), DVD támogatás

22. Az s5fs • A fájlrendszer egyetlen diszk partíciót foglal el, használatához más információ kell • A partíció logikailag blokkok lineáris tömbjének tekinthető • A blokkok mérete 512 szorzata 2 egész számú hatványával • A diszk műveletek előtt a blokkok címét át kell fordítani a lemez fizikai címadataira • A partíció négy részből áll • Boot terület • Szuper blokk • i-node lista • adatterület

23. Fájlok tárolása • Kb. fa struktúrájú szervezés, a struktúrát a könyvtár fájlok írják le. Felépítés: • Fájl neve 14 karakteren • i-node szám, 2 bájton (0 érték foglalt, törölt fájlt jelöl) • A ‘.’ és ‘..’ minden könyvtárban kötelező, root könyvtár i-node értéke: 2 • Index node fájl adatait tárolja (kivétel név) • Fájl elhelyezkedésének magadása: indexelt, 13 bejegyzés, ebből 3 indirekt • Lyukak támogatása fájlokban (ilyenkor a blokkcím 0) • Másoláskor gond lehet…

24. Szuperblokk • A fájlrendszer metaadatait tartalmazza • Minden fájlrendszer tartalmaz egy ilyen blokkot • Csatoláskor a kernel memóriába tölti, leválasztásig ott is marad • Szuperblokkban tárolt adatok • Fájlrendszer mérete (blokkok) • I-node lista mérete (blokkok) • Szabad blokkok és i-node bejegyzések száma • Szabad blokkok listája • Szabad I-node bejegyzések listája

25. Szuperblokk, folyt. • Szabad i-node blokkok nyilvántartása • Csak részleges lista van a szuperblokkban • Ha elfogy, a rendszer szabad blokkokat keres a diszken • Szabad diszk blokkok nyilvántartása • Az összes szabad blokkot nyilván kell tartani • Teljes lista szuperblokk-ban tartása nem lehetséges • A szuperblokkban csak a lista „eleje” van, a többi tárolása adatblokkokban történik • Minél jobban telített a diszk, annál kisebb ez a lista!

26. Cache • Korai megoldásokban különálló buffer cache • SVR4 esetén a fájlkezelés a virtuális memóriakezeléssel integrált • Olvasási művelet (példa) • Blokk diszk-beli címének meghatározása • Lap foglalás kernelben, megadva az előbb kiszámolt cím • Lap másolása felhasználói térbe – laphiba, adatterület beolvasása • Az írás is virtuális memórián át történik, de: • A fájl mérete változhat • Ha nem teljes blokkot ír, akkor visszaíráskor szükség van a diszken található adatokra is

27. A fájlrendszer értékelése • Egyszerűsége kiemelkedő, de problémák több területen is jelentkeznek: • Megbízhatóság • Teljesítmény • Szolgáltatások • A szuperblokk sérülése a teljes fájlrendszert tönkreteszi • Teljesítmény szempontjából kritikus a teljes i-node tábla partíció elején való elhelyezése • Az i-node foglalás véletlenszerű, nem ügyel kapcsolatokra (pl. egy könyvtár fájljai) • A fájlrendszer létrehozásakor a szabad blokkok listája optimális (a diszk műveletekre nézve), később azonban ezzel nem foglalkozik • A diszk blokkok mérete szintén nem optimális (nagyobb méret, kevesebb művelet – jobb teljesítmény, de sok pazarlás) • A 14 karakteres fájlnév komoly funkcionális korlát

28. Berkeley FFS • Az FFS célja az s5fs korlátainak túllépése volt • Teljesítmény-növelés • Bár a fájlrendszer továbbra is blokkok tömbjének tekinthető, a műveleteknél figyelembe veszi a diszkek forgási késleltetését • A fejmozgások csökkentése érdekében a partíciót tovább osztjuk, ún. cilinder csoportokat hozunk létre • Cél az összetartozó adatok egy cilinder-csoportban tartása • A szuperblokk adatainak egy része is a cilinder-csoportokba vándorol • Biztonság növelés érdekében a szuperblokk több példányban „elszórtan” tárolódott • A helykihasználás javítása (és a teljesítmény növelése) miatt a (s5fs-nél nagyobb méretű) blokkokat oszthatóvá tették

29. Fájlfoglalási politika • Fájlfoglalás optimalizálása cilinder-csoportokon keresztül • Egy könyvtár fájljai egy csoportba kerülnek (lokalitás, gyors könyvtárműveletek) • Új alkönyvtárat eltérő csoportba helyezi • A fájl blokkokat egy csoportba helyezi az i-node blokkal • A nagy fájlokat „szétkeni” a blokkok között • Szekvenciális blokkok elhelyezése a diszk forgás függvényében (késleltetések) • Az optimális működéshez legalább 10% szabad diszk terület szükséges!

30. Új szolgáltatások • Hosszú fájlnevek (255 karakter) • Tárolás változó hosszon a könyvtár fájlokban (a fix 255 hossz túlzás lenne) • Szimbolikus linkek • Stb.

31. Blokkok osztása • A nagy(obb) blokkméret jót tesz a teljesítménynek, de helyet fecsérelhet • 1 transzfer alatt átvihető adatmennyiség • Az FFS egy fájlrendszeren belül csak egyféle blokkméretet támogat (ez általános) • A blokkméret 2 hatványa, legalább 4096 byte • Ezzel a mérettel már elég a kétszeres indirekció • Kis fájlok miatt az FFS támogatja blokk töredékek használatát • Csak a fájl utolsó blokkja lehet töredéken, a többi csak teljes blokkot foglalhat (emiatt néha mozgatni is kell)

32. Értékelés • S5fs-hez képes jelentős teljesítmény növekedés • 1983: olvasás ~8x, írás ~3x • Fájlrendszer kihasználási hatékonyság hasonló • Több tényező, kiegyenlítik egymást • Mai diszkek esetén a sávonkénti blokkok száma eltérő, így az FFS elhelyezési politikája többé-kevésbé elévült • Összességében az FFS jelentős előrelépés a s5fs-hez képest, azonban innen van még hova fejlődni

33. Speciális fájlrendszerek, tmpfs • Átmeneti adattárolás (tmp terület) • Sok alkalmazás intenzíven használ átmeneti fájlokat – a teljesítmény fontos, a hosszú távú megőrzés szükségtelen • Sokáig az ún. RAM diszkek használata volt a tipikus, ez viszont a központi memóriát statikusan foglalja • A különféle speciális fájlrendszer megoldások (pl. Berkeley mfs, Sun tmpfs) dinamikusan használják a (virtuális) memóriát • a tmpfs akár nagyobb is lehet, mint a fizikai memória • a két megoldás közül a tmpfs a fejlettebb

34. Speciális fájlrendszerek, procfs • Cél hatékony és elegáns hozzáférés biztosítása a folyamat-adatokhoz (kernel adatok) • A folyamatok adatait fájlok reprezentálják, hozzáférés egyszerű fájl I/O műveletekkel • Az adathozzáférés (pl. státusz, creditentals, címtér) mellett (olvasás, esetenként írás) vezérlés is lehetséges (stop, resume, signal)

35. Tradicionális fájlrendszerek korlátai • Teljesítmény • Még az FFS sávszélessége is jelentősen elmarad a diszk potenciális sávszélességétől • Összeomlás esetén • A cache miatt adat és metaadat is elveszhet, helyreállás során hosszadalmas konzisztencia ellenőrzés (fsck) szükséges • Minél nagyobb a diszk, annál tovább tart • Biztonság • A klasszikus Unix hozzáférés kontroll sokszor nem elég finom, ACL-re lenne szükség • Méretek • A 32 bit korlátjai…

36. Naplózás (journaling) • Alapkoncepció (jelentősen leegyszerűsítve) • Minden változást feljegyzünk egy szekvenciális fájlba (is) • Hiba esetén csak a fájlt kell ellenőrizni (végrehajtatlan tranzakciókat keresve) • Megvalósítás • Jelentős számú tervezési kérdés • Valós referenciák (pl. már a standard Solaris fájlrendszernek is része a naplózási opció)

37. Tervezési kérdések • Naplózás köre: mindent v. metaadat változások • Műveletek vagy értékek naplózása • A napló kiegészíti vagy kiváltja a fájlrendszert • Redo vagy undo-redo logok • Szemétgyűjtés (naplófájl nem használt részei) • Írási szemcsézettség (egyedi, csoport) • Adatvisszanyerés teljesítménye (főleg a kiváltó megoldásoknál)