Operációs Rendszerek II.

13. előadás

2007. május 7.

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ő

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)

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

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…

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

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

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

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

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

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…

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

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!

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

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

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

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!

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

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)

É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

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

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)

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…

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ó)

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)