Operációs Rendszerek II. 6. előadás

Operációs Rendszerek II. 6. előadás

Sunday, March 21, 2010

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


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)


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 Giga ethernet Grafikus megjelenítő HDD


Átviteli sebesség (10n bps) 9 10 (PCI Express) 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.


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. változatosság ellenére várjuk, • Az A átvitel egysége: adatokat bájtokazt vagy karakterek folyamaként is átvihetjük, de kezelhetjük az adatokat hogy az operációs rendszer az I/O kezelést összefüggő blokkokban is. eszközfüggetlen interfészen • Azegységes, adatok megjelenése: különböző eszközök az a d a t o kkeresztül a t m á s - mbiztosítsa á s k ó d o l á számunkra 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.


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


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ú


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


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” (ondemand) 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 • Egyszeres puffer • 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 • Egyszeres puffer • 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


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ű!


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!


SSD • Új, ígéretes, drága, saját problémákkal • Jellemzői (HDD-hez képest): – Rendkívül rövid késleltetés (latency) – Lassabb írás és olvasás – Nagyon lassú törlés (kötelező) – „Wear-out” – egy adott terület csak véges számú alkalommal írható (kb. 1.000.000 írás)

23 Sunday, March 21, 2010

SSD „felépítés”

Forrás: http://www.usenix.org/event/usenix08/tech/full_papers/agrawal/agrawal_html/


SSD teljesítmény (2007)

Forrás: http://managedflash.com/news/papers/easyco-flashperformance-art.pdf


Olvasási teljesítmény


• SSD esetén a tulajdonképpeni olvasás lassabb, de a késleltetés nagyon kicsi! 26 Sunday, March 21, 2010

Teljesítmény arányok (2007)


• Írás esetén a törlést is figyelembe kell venni, ami rendkívüli mértékben visszafog! 27 Sunday, March 21, 2010







Mit jelent ez? • SSD hatékony használata új megoldásokat kíván a „hagyományos” diszkekhez képest – Flash specifikus fájlrendszerek – Speciális Flash driver-ek


Hol használjuk (jelenleg)? • Hordozható fogyasztói eszközök (pl. kamerák) • Laptop HDD-k • Gyorsító megoldás adatbázis rendszerekben és „enterprise” kategóriájú rendszerekben (pl. Sun 7xxx sorozatú Unified Storage rendszerek)


A következő diákon tárgyaltak alapvetően a hagyományos merevlemezekre igazak!


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


RAID-3 •

Tárolás módja – 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)


RAID-4 •

Tárolás módja – 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!

•

Írás – Egy időben 1 írási tranzakció szolgálható ki. • 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


RAID-4 •

Tárolás módja – 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


•

Írás – Egy időben 1 írási tranzakció szolgálható ki. • Tranzakciónkénti átviteli sebesség << T. Egy blokk kiírása után a teljes sor paritását újra kell számolni



RAID-5 •

Tárolás módja – 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


•

Írás – Egy időben 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)


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) drwx------ 16 bzso bzso drwx------ 35 bzso bzso -rwxr-xr-x 1 bzso bzso -rwxr-xr-x 1 bzso bzso


544 Mar 24 22:48 Documents 1190 Apr 3 18:24 Library 99452 Nov 1 00:46 Google Earth 92840 Nov 1 01:02 Google Earth Launcher

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) drwx------ 16 bzso bzso drwx------ 35 bzso bzso -rwxr-xr-x 1 bzso bzso -rwxr-xr-x 1 bzso bzso

544 Mar 24 22:48 Documents 1190 Apr 3 18:24 Library 99452 Nov 1 00:46 Google Earth 92840 Nov 1 01:02 Google Earth Launcher

crw-rw-rw- 1 root wheel crw-rw-rw- 1 root wheel crw-rw-rw- 1 root wheel

10, 6 Apr 18 23:20 tty.Bluetooth-Modem 10, 2 Apr 18 23:20 tty.Bluetooth-PDA-Sync 10, 4 Apr 18 23:20 tty.Hermione-Dial-upNetwork-2

brw-r----- 1 root operator 14, 0 Apr 18 23:19 disk0 brw-r----- 1 root operator 14, 1 Apr 18 23:19 disk0s1 crw-rw-rw- 1 root wheel crw-rw-rw- 1 root wheel crw-rw-rw- 1 root wheel Sunday, March 21, 2010

3, 2 Apr 19 00:20 /dev/null 3, 3 Apr 18 23:19 /dev/zero 8, 1 Apr 18 23:19 /dev/urandom

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)


Operációs Rendszerek II. 6. előadás

Recommend Documents