operációs rendszerek ii

Operációs Rendszerek II.

10. előadás

2007. április 16.

I/O kezelés

• I/O eszközök

• I/O szervezés

• Operációs rendszeri elvárások

• Diszkek kezelése– RAID

• Fájlrendszerek

I/O eszközök csoportosítása

• Csoportosítás kapcsolódás fajtája szerint– Felhasználói kapcsolat (bevitel és kivitel is)– Gép általi kapcsolat (pl. HDD, tape)– Kommunikáció (gép-gép közötti)

• A fenti csoportokba tartozó eszközök között is jelentős eltérések lehetnek további jellemzők vizsgálata szükséges!

I/O eszközök jellemzői

1. Adatátviteli sebesség (Data rate)

2. Felhasználási terület (Application)

3. Vezérlés összetettsége (Complexity of control)

4. Adatátvitel egysége (Unit of transfer)

5. Adatok megjelenése (Data representation)

6. Hibalehetőségek (Error conditions)

Adatátviteli sebesség

• Különféle eszközök átviteli sebessége között több nagyságrendi eltérés is lehet

– Billentyűzet kevesebb, mint 100 bps– Ethernet: 109 bit/sec

• A sávszélesség nem köthető a kapcsolat fajtájához!

Eszköz Átviteli sebesség (10n bps)

Giga ethernet 9

Grafikus megjelenítő 10 (PCI Express)

HDD 9 (Seagate: 78 MB/s)

Felhasználási mód (terület)

• Az eszköz felhasználási területe befolyásolja, hogy az operációs rendszernek milyen módon kell azt kezelnie– Például a lemezegységek használatához

általában fájlkezelő rendszer szükséges, azonban ha a lemezegységet a memória lapok tárolására használjuk (másodlagos memória) a fájlkezelés helyett másfajta lemezkezelésre lesz szükség

További jellemzők

• Vezérlés összetettsége: egy mátrixnyomtató kezelése viszonylag egyszerű feladatot ró az operációs rendszerre, ugyanakkor egy lemezegység kezelése meglehetősen összetett feladat.

• Az átvitel egysége: adatokat bájtok vagy karakterek folyamaként is átvihetjük, de kezelhetjük az adatokat összefüggő blokkokban is.

• Az adatok megjelenése: különböző eszközök az adatokat más-más kódolásban igényelhetik (karakterkódok, paritás, stb.).

• Hibalehetőségek: hibák jellege, a hibajelentés módja, és a hiba fellépése esetén elvégzendő intézkedések fajtáji eszközről-eszközre változnak.

A változatosság ellenére azt várjuk, hogy az operációs rendszer az I/O kezelést

egységes, eszközfüggetlen interfészen keresztül biztosítsa számunkra

I/O szervezés lehetőségei

• I/O kezelési technikák– Programozott I/O– Megszakítás vezérelt I/O– DMA alapú I/O

• Az I/O funkciók fejlődése– A processzor direkt vezérli az eszközöket– Kontroller (I/O modul) hardver hozzáadása– Megszakítások kezelése (I/O modul)– DMA megjelenése– Az I/O modul egy programozható célprocesszorként jelenik meg.

A központi CPU feladata a programkód megadása és a folyamat indítása (I/O csatorna)

– Az I/O processzor nem a központi memóriát használja, hanem dedikált memóriával rendelkezik

Operációs rendszer elvárások

• Hatékonyság– az I/O eszközök többsége a CPU-hoz képest lassú– az I/O kezelő funkciókat úgy kell elkészíteni, hogy a lassú

eszköz miatti várakozás során más folyamat futhasson – ma már léteznek olyan gyors perifériák, amelyek kiszolgálása

jelentős teljesítmény-optimalizálást igényel

• Általánosság: sokszínűségük ellenére egységes periféria-kezelési megoldás – OS szintjén (belső struktúrák)– folyamatok felé nyújtott interfészen (read, write, open, close,

lock, unlock) keresztül – megoldást a hierarchikus struktúrák alkalmazása jelenti

I/O funkciók logikai struktúrája

• Klasszikus megoldás: hierarchikus megközelítés, az egyes rétegek csak a saját feladatukért „felelnek”– Logikai I/O: általános I/O funkciók

szolgáltatása a folyamatok felé– Eszköz I/O: I/O kérések „lefordítása” eszköz

specifikus parancs-szekvenciákra– Ütemezés, vezérlés: I/O műveletek sorba

állítása, ütemezés (pl. IRQ-k kezelése)

I/O Pufferelés

• Ha az eszközök közvetlenül „csatoltak” a folyamathoz, akkor:– az érintett memória lapok nem lapozhatók– a művelet befejeztéig a folyamatnak várnia kell (az

adott terület nem módosítható)– beviteli műveletek esetén csak az „igény szerinti” (on-

demand) működés képzelhető el

• Pufferelés: egy kernel területén található átmeneti tár közbeiktatásával szétválasztjuk az eszközt és a folyamatot

Pufferelési módok

• Egyszeres puffer

• Dupla puffer

• Cirkuláris pufferek

Pufferelési módok

• Egyszeres puffer– A műveletek egy kernel puffer- be/ből történnek. – A kernel-user címtér utáni mozgatás után a puffer

felszabadul (kezdődhet a következő művelet)– A user címtér lapozható (de a memória menedzsment

elbonyolódik)

• Dupla puffer• Cirkuláris pufferek

Pufferelési módok


• Dupla puffer– Két puffert használunk, az egyiket az OS, a

másikat a user folyamat „fogja”– Két művelet történhet egy időben– Gyorsabb, mint az egyszeres – de

bonyolultabb is

• Cirkuláris pufferek

Pufferelési módok


• Dupla puffer

• Cirkuláris pufferek– A dupla pufferelés továbbgondolása, a kernel

n puffert rendel egy folyamathoz– Bizonyos esetekben tovább gyorsít– A megoldás a „termelők-fogyasztók” modellel

írható le

Diszk I/O

• Probléma: diszk és CPU/Mem közötti sebesség különbség folyamatosan növekedett az elmúlt időben (és valószínűleg ez így is marad): – diszkek több nagyságrenddel „lassabbak” a CPU-nál

• Mivel a leggyakoribb I/O művelet a diszkekkel kapcsolatos (fájl, VM) a diszkkezelés hatékonysága alapvető fontosságú az operációs rendszerek számára

Diszkek teljesítményének elemei

• Elemek– Seek time: a fej mozgásának ideje (megfelelő track

fölé)– Forgási késleltetés: amíg a track-on belül a kívánt

blokk befordul– Átviteli idő: a konkért írás vagy olvasás

• A seek time és a forgási késleltetés összege adja az elérési időt.

• A fenti időkön túl még számolni kell: – az eszközre való várakozás ideje – I/O csatornára való várakozás ideje (ha az osztott)

Idők, értékek

• Seek time– A fej mozgásához szükséges idő. Ez a mozgás nem teljesen

lineáris. A mai kisebb diszkek esetén rövidebb, mint a régi nagyobb (pl. 14 inch) lemezeknél. Mai jellemző érték 4…10 ms.

• Forgási késleltetés– A lemez forgási sebességétől függ– Mai HDD-k esetén a 3.600 és a 15.000 közötti percenkénti

fordulatszám a jellemző (a 3.600 csak a low-end, hordozható eszközökben)

– 15k esetén egy teljes fordulat ideje 4ms, így az átlag 2ms! • Átviteli idő:

– Szintén a fordulatszám függvénye. Egy track-en belül számítható: T = b/(rN)

– b: átviendő bájtok, r: forgási sebesség, N: track mérete (byte)

Játék a számokkal

• Példadiszk– átlagos seek idő: 4ms– fordulatszám: 15.000 (full: 4 ms)– szektorméret: 512 byte– szektor/track: 500 (16 us)

• Feladat: 2500 szektor (1.28 MB beolvasása)• Scenario 1: összefüggő elhelyezkedés – 5 track

– 1. track: seek + forgás + 500 rekord olvasása = 10 ms– 2...5. track: 4x(forgás + olvasás) /no seek/ = 24 ms– Összesen: 34 ms

Játék a számokkal

• Példadiszk– átlagos seek idő: 4ms– fordulatszám: 15.000 (full: 4 ms)– szektorméret: 512 byte– szektor/track: 500 (16 us)

• Feladat: 2500 szektor (1.28 MB beolvasása)• Scenario 2: véletlenszerű elhelyezkedés

– 2500 x (átlagos seek + átl. Forgás + olvasás)– 2500 x (4m+2m+16u) = 14.6s!– Összesen: 14.6 s

Játék a számokkal - tanulságok

• 34 msec vs. 14.6 sec

• Fájlrendszereket célszerű úgy szervezni, hogy a fájlok elhelyezkedése ne legyen teljesen véletlenszerű!

• Multiprogramozott rendszerek esetén az egymástól független I/O műveletek esetén érdemes optimalizációt végezni!

Diszk ütemezés

• diszk kérések hatékony kiszolgálása (multiprg. rendszerekben)– Tökéletes megoldás nincs

• Algoritmusok– FIFO– Prioritásos– LIFO– SSTF– Scan (és változatai)

Diszk ütemezési algoritmusok

• FIFO: kiszolgálás a beérkezés sorrendjében. – Korrekt ütemezés, kevés számú folyamatnál hatékony is lehet – Sok folyamatnál hatékonysága drasztikusan romlik

• Prioritásos: mindig a legnagyobb prioritású kérést– Kiéheztetés lehetséges

• LIFO: Mindig a legfrissebb kérést szolgálja ki– Filozófiája lényege, hogy az utolsó kérés az előző közelében

lehet – így gyorsan kiszolgálható – Sok folyamatnál ez nem feltétlenül igaz – Kiéheztetés lehetséges

• SSTF: mindig a legrövidebb kiszolgálási időt igénylő (legkisebb fejmozgás) tartozó kérést szolgálja ki – A megoldás nem garantálja, a fejmozgások globális minimumát– Kiéheztetés lehetséges

Folytatás, SCAN verziók

• Scan: – Cél a hatékonyság növelése a a kiéheztetést elkerülése mellett

(ezt eddig csak a FIFO oldotta meg)– A fej fel-le mozog, és minden útjába akadó kérést kiszolgál.

• középső részeket favorizálja• tömeges kérésekkel „leragasztható”

• C-Scan: mindig csak egy irányba megy, – a Scan első problémáját megoldja

• N-step-Scan: a diszk sort N nagyságú részekre osztja, egyszerre csak egy N-est dolgoz fel

• FSCAN: két sor van. Amíg az egyikből dolgozik, a kérések a másikba gyűlnek– e két megoldás a leragadást oldja meg

Név Leírás Megjegyzés

A kiválasztás a művelet igénylőjétől függ

FIFO FIFO elv A legkorrektebb

Prioritásos A folyamat prioritása alapján Független a diszk ütemezőtől

LIFO LIFO A lokalitás maximalizálja

A kiválasztás a kért elemek függvénye

SSTF Shortest Service Time First Magas kihasználtság

SCAN Felvonóként Korrekt, de gyengékkel

CSCAN Egyirányú gyűjtőlift Megjósolhatóbb szolgáltatás

N-Step-SCAN Fix számú rekordot dolgoz fel Garantált szolgáltatás

FSCAN Változó rekordszám Érzékeny a terhelésre

RAID

• Diszk (másodlagos tároló) problémák– Teljesítményük növekedési rátája szignifikánsabban

alacsonyabb a CPU növekedésnél– a tárolt adatok fontossága miatt a nagy kapacitású diszkek

hibája egyre nagyobb üzleti kockázattal járt– A nagy kapacitású diszkek sem „eléggé nagyok”

• RAID koncepciója: nagy kapacitású és teljesítményű drága diszkek helyett kisebb (olcsóbb) diszkeket használva érjük el célunkat, azaz:– Kapacitás növelése– Teljesítmény növelése– Megbízhatóság növelése

RAID• Az elnevezés a Berkley egyetem kutatóitól származik (1988) –

akkor ők ezt a „Redundant array of Inexpensive Disks” szavakból állították össze. A névben később az „Inexpensive” szó „Independent”-re változott…

• Dióhéjban: úgy kapcsolunk össze több diszket, hogy– az operációs rendszer számára egy diszknek látszanak– az adatot szétosztjuk a diszkek között,– a diszk hibák ellen paritás információ tárolásával védekezzünk (ezt– két megoldás nem elégíti ki)

• A szabvány 5+1 szintet definiál – a „+1” nem redundáns és 3 terjedt el– különböző gyártók további szinteket is definiálnak– szint-kombinációkat is alkalmazunk

• A különböző megoldások a szükséges tárolóterület overhead-ben, a megoldás teljesítményigényében és a biztonság szintjében térnek el

RAID szintek• RAID-0 (striping)

– Redundancia nélküli megoldás• RAID-1 (tükrözés)

– Adatduplikáláson alapul (nem paritás alapú)• RAID-2

– Speciális, Hamming kód alapú– Gyakorlatilag kihalt

• RAID-3– Kizáró vagy műveletre épít, egy blokk az összes diszkre szét van osztva– Erős hardver támogatást igényel!

• RAID-4– Kizáró vagy műveletre épít, egy blokk csak egy diszken található– Dedikált paritás diszket használ

• RAID-5– Hasonló a RAID-4 megoldáshoz, de itt a paritás is szét van osztva a diszkek

között

RAID – háttér információk

• A diszkek átviteli jellemzőjének tényezői– a mechanikai működésből adódó késleltetés– az adatátvitel végrehajtásának teljesítménye (átviteli sebesség)

• A terhelés jellege – Kevés számú, kis párhuzamosságú, de nagy mennyiségű adatot

mozgató terhelése (pl. kötegelt feldolgozás)– Nagy számú, magas párhuzamosságú, de kicsi

adatmennyiséget érintő terhelés (tranzakciós rendszerek)

• Kapcsolat a fentiek között– Nagy mennyiségű adatot mozgató terhelésnél az adatátvitel

teljesítménye domináns– Nagy tranzakciószámnál a késleltetések sokkal fontosabbak

RAID – háttér információk

• Olvasás és írás műveletek különbsége redundáns tároláskor– olvasáskor csak annyi adatot kell beolvasni, ami elegendő a kért

adatblokk biztosításához– íráskor az adatblokkhoz tartozó összes részt aktualizálni kell

• Vizsgáljuk– Tárolás módja– Viselkedés íráskor és olvasáskor

• Példák– Diszkek száma: N– Egy diszk átviteli sebessége: T

RAID-0

• Tárolás módja– Nagyméretű csíkok, egy blokk egyetlen diszken tárolódik. – Redundancia nincs a rendszerben. – Hasznos terület: N.

• Olvasás– Egy időben ~N független olvasási tranzakció szolgálható ki.

• Tranzakciónkénti átviteli sebesség: T

– Hiba esetén: működésképtelen!

• Írás– Egy időben ~N független írása tranzakció szolgálható ki.

• Tranzakciónkénti átviteli sebesség: T

– Hiba esetén: működésképtelen!

RAID-1• Tárolás módja

– Nagyméretű csíkok, egy blokk egyetlen diszken tárolódik. – A redundanciát a teljes adat duplikálása eredményezi. – Tipikusan N=2, hasznos terület: N/2.

• Olvasás– Egy időben ~N független olvasási tranzakció szolgálható ki.

• Tranzakciónkénti átviteli sebesség: T– Hiba esetén: egy időben ~(N-1) független olvasási tranzakció

szolgálható ki. • Tranzakciónkénti átviteli sebesség: T

• Írás– Egy időben 1 írási tranzakció szolgálható ki.

• Tranzakciónkénti átviteli sebesség: =< T– Hiba esetén: Egy időben 1 írási tranzakció szolgálható ki.

• Tranzakciónkénti átviteli sebesség: =< T


– Byte szintű csíkok, a blokkok az összes diszkre szét vannak osztva. – Byte szintű paritás képzés XOR művelettel történik, – a megoldás dedikált paritás diszket használ. N>2, hasznos terület: N-1.

• Olvasás– Egy időben 1 olvasási tranzakció szolgálható ki

• Tranzakciónkénti átviteli sebesség: (N-1)*T– Hiba esetén: egy időben 1 olvasási tranzakció szolgálható ki

• Tranzakciónkénti átviteli sebesség: < (N-1)*T (számolni kell)• Írás

– Egy időben 1 írási tranzakció szolgálható ki. • Tranzakciónkénti átviteli sebesség: <= (N-1)*T (számolni is kell)

– Hiba esetén: egy időben 1 írási tranzakció szolgálható ki. • Tranzakciónkénti átviteli sebesség: <= (N-1)*T (számolni is kell)


– Nagyméretű csíkok, egy blokk egyetlen diszken tárolódik. – Blokk szintű paritás képzés XOR művelettel történik, a megoldás

dedikált paritás diszket használ. – N>2, hasznos terület: N-1.

• Olvasás– Egy időben (N-1) független olvasási tranzakció szolgálható ki.

• Tranzakciónkénti átviteli sebesség: T– Hiba esetén: az olvasási tranzakciók száma akár egyre is lecsökkenhet,

mert a hibás diszkeken található adatok előállításához az összes többi diszkblokk adata szükséges!


• Tranzakciónkénti átviteli sebesség << T. Egy blokk kiírása után a teljes sor paritását újra kell számolni

– Hiba esetén: 1 írási tranzakció szolgálható ki. • Tranzakciónkénti átviteli sebesség << T


– Nagyméretű csíkok, egy blokk egyetlen diszken tárolódik. – Blokk szintű paritás képzés XOR művelettel történik, a paritás blokkok is

szét vannak osztva a diszkek között. – N>2, hasznos terület: N-1.

• Olvasás– Egy időben (N-1)...(N) független olvasási tranzakció

• Tranzakciónkénti átviteli sebesség: T– Hiba esetén: az olvasási tranzakciók száma akár egyre is lecsökkenhet,

mert a hibás diszkeken található adatok előállításához az összes többi diszkblokk adata szükséges!


• Tranzakciónkénti átviteli sebesség << T– Hiba esetén: 1 írási tranzakció szolgálható ki.

• Tranzakciónkénti átviteli sebesség << T

További RAID szintek

• Raid-6– Két paritás blokk használatával (n+2 konfig) nagyobb hibatűrést

biztosít– Az írás során jelentős overhead– Nem igazán terjedt el

• Raid-S– EMC Symmetrix diszktömbökben használt technológia. – Raid-5 szerű, de speciális, teljesítményt növelő eljárásokat

alkalmaz

• Kombinált Raid: 1+0 és 0+1 – 0+1: összetükrözi a stripe-ot– 1+0: tükröket stripe-ol

Diszk cache

• Gyorsítótár, a gyorsítótáraknál korábban megismert célokkal és problémákkal– Gyorsítótár: központi memória (drágább,

kisebb kapacitású, de gyorsabb, mint a merevlemez)

– Algoritmusok: gyorsítótár lehető legoptimálisabb használata

Diszk cache tervezési kérdések

• Gyorsítás „iránya”– Csak olvasáskor (write through)– Mindkét irányban (write back)

• Memória felhasználás módja– Fix (előre meghatározott)– Dinamikus (terheléstől függő)

• Adat átadás a cache-területről (olvasáskor)– Másolás a felhasználói címtérbe– Osztott memória használata

• Blokkcsere algoritmusa– LRU (least recently used)– LFU (least frequently used)– Frequency-based

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

Másodlagos tároló menedzsment tervezési tere

• Fájl foglalása– Előzetes foglalás: a létrehozáskor lefoglaljuk (fix méret)– Dinamikus foglalás

• Foglalási egység– változó hosszú, ö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 – viszont könnyen módosítható és újrahasználható• 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)

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

Unix I/O (klasszikus)

• Hozzáférés fájl-interfészen keresztül

• Kétféle eszköz– Blokkos– Karakteres

• Eredeti buffer cache fix

I/O eszközök a fájlrendszerben• Kernel tábla hivatkozások az i-node táblában

– Major és minor numberek (eszköz, példány)

crw-rw-rw- 1 root wheel 10, 6 Apr 18 23:20 tty.Bluetooth-Modemcrw-rw-rw- 1 root wheel 10, 2 Apr 18 23:20 tty.Bluetooth-PDA-Synccrw-rw-rw- 1 root wheel 10, 4 Apr 18 23:20 tty.Hermione-Dial-upNetwork-2

brw-r----- 1 root operator 14, 0 Apr 18 23:19 disk0brw-r----- 1 root operator 14, 1 Apr 18 23:19 disk0s1

crw-rw-rw- 1 root wheel 3, 2 Apr 19 00:20 /dev/nullcrw-rw-rw- 1 root wheel 3, 3 Apr 18 23:19 /dev/zerocrw-rw-rw- 1 root wheel 8, 1 Apr 18 23:19 /dev/urandom

drwx------ 16 bzso bzso 544 Mar 24 22:48 Documentsdrwx------ 35 bzso bzso 1190 Apr 3 18:24 Library-rwxr-xr-x 1 bzso bzso 99452 Nov 1 00:46 Google Earth-rwxr-xr-x 1 bzso bzso 92840 Nov 1 01:02 Google Earth Launcher

Unix I/O

• Klasszikus: statikus táblázatok– Új hardver illesztéséhez új kernel kell (a meghajtó

programok statikusan betöltve)– Sok esetben előre „belepakoltak” minden drivert a

kernelbe

• Modern: dinamikus kernelek– A különféle meghajtó programok futási időben is

betölthetők (igény szerint)• Függőségek!

– Lényegesen rugalmasabb és erőforrás takarékosabb működés – de a kernel sokkal bonyolultabb lesz

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