Operációs rendszerek 2 Bringye Zsolt 2012-es előadásdiái alapján készítette: Pintér Gergő 2012. június 7.
Jelen dokumentum anyaga (ábrák, táblázatok, stb.) Bringye Zsolt 2012-es előadásdiáiból származik, a diákban nem szereplő megjegyzéseket kék színnel írtam. Dokumentumverzió: v1.1
1
Tartalomjegyzék 1. Mi az operációs rendszer? 1.1. Black-box leírás . . . . . . . . . . 1.2. Felhasználói interfész . . . . . . . 1.3. Felhasználói csoportok . . . . . . 1.4. Felhasználói felületek . . . . . . . 1.5. Alkalmazási Programozói Felület 1.6. Hardver Interfész . . . . . . . . 1.7. Interfészek, határok . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
7 7 7 7 8 8 8 8
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
2. Operációs rendszerek fejlődése 2.1. Operációs rendszer nélkül . . . . . . . . 2.2. Egyszerű kötegelt feldolgozás . . . . . . 2.3. Multiprogramozott kötegelt feldolgozás . 2.4. Időosztásos rendszerek . . . . . . . . . . 2.5. Kötegelt vs. időosztásos . . . . . . . . . 2.6. Személyi számítógépek . . . . . . . . . . 2.7. Valós idejű rendszerek . . . . . . . . . . 2.8. Elosztott rendszerek . . . . . . . . . . . 2.9. PDA-k, telefonok, beágyazott rendszerek 2.10. „Hol a helyük”? . . . . . . . . . . . . . . 2.11. Van még tovább? . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
8 . 8 . 9 . 9 . 9 . 9 . 9 . 9 . 9 . 9 . 10 . 10
3. Operációs rendszerek és a hardver 3.0.1. Hardver . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Nincs operációs rendszer . . . . . . . . . . . . . . . . . . . . 3.2. Minimál operációs rendszer . . . . . . . . . . . . . . . . . . 3.3. A „minimál OS” világán túl: Multiprogramozott rendszerek 3.3.1. Több program egyidejű futtatása . . . . . . . . . . . 3.3.2. Váltás programok között . . . . . . . . . . . . . . . 3.3.3. Védelem . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4. Operációs rendszeri szolgáltatások . . . . . . . . . . 3.3.5. Multiprogramozott OS értékelése . . . . . . . . . . . 3.4. Miért hibás, késik? . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. A méret következményei . . . . . . . . . . . . . . . . 3.4.2. A változás mozgatórugói . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
10 10 11 11 11 11 11 12 12 12 12 12 12
4. Unix történelem 4.0.3. A BSD Unix . . . . . . . . . . 4.0.4. Mach . . . . . . . . . . . . . . 4.1. A Unix háború . . . . . . . . . . . . . 4.2. A közelmúlt . . . . . . . . . . . . . . . 4.3. Szabványok . . . . . . . . . . . . . . . 4.4. Összefoglalva . . . . . . . . . . . . . . 4.5. Solaris – példa az „új” Unix-ra . . . . 4.5.1. Klasszikus (pre. SVR4) kernel 4.5.2. „A Solaris előtt” . . . . . . . . 4.5.3. „Solaris 2 és azon túl” . . . . . 4.5.4. A Solaris 2 kernel . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
13 14 14 14 14 14 15 16 16 17 17 17
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
5. Konszolidáció, virtualizáció
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
17
2
6. Linux 6.1. verziók . . . . . . . . 6.2. Jellemzők . . . . . . 6.3. Linux kernel . . . . . 6.4. Szabványos felületek 7. Windows 7.1. A Microsoft „korai” 7.2. Roadmap . . . . . 7.3. Elvárások: 1989 . . 7.4. Célok és jellemzők 7.5. Kernel . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
17 18 18 18 19
operációs rendszerei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
19 19 19 19 19 20
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
8. Folyamatok 8.1. Mi a folyamat? . . . . . . . . . . . . . . . . . . . 8.2. Folyamatok állapotai . . . . . . . . . . . . . . . . 8.2.1. Kétállapotú modell . . . . . . . . . . . . . 8.2.2. Három állapotú modell . . . . . . . . . . 8.2.3. Három állapotú modell bővítés . . . . . . 8.2.4. Öt állapotú modell . . . . . . . . . . . . . 8.2.5. Hét állapotú modell . . . . . . . . . . . . 8.2.6. Valós állapot modellek (Unix) . . . . . . . 8.3. Folyamatok közötti váltás . . . . . . . . . . . . . 8.3.1. Folyamatváltás háttere . . . . . . . . . . . 8.3.2. Mód váltás . . . . . . . . . . . . . . . . . 8.4. Folyamatok létrehozása (Windows) . . . . . . . . 8.4.1. Végrehajtható fájl . . . . . . . . . . . . . 8.5. Folyamatok létrehozása (Unix) . . . . . . . . . . 8.5.1. Folyamat duplikálás – fork() . . . . . . . . 8.5.2. fork() másik példa . . . . . . . . . . . . . 8.5.3. Fork() működése . . . . . . . . . . . . . . 8.5.4. exec() . . . . . . . . . . . . . . . . . . . . 8.6. Folyamat-leírók . . . . . . . . . . . . . . . . . . . 8.7. Operációs rendszer végrehajtása . . . . . . . . . . 8.7.1. Modellek . . . . . . . . . . . . . . . . . . 8.7.2. Kernel kód futtatása folyamat címterében 8.7.3. Folyamat alapú kernel . . . . . . . . . . . 8.8. Mikrokernelek – miért? . . . . . . . . . . . . . . . 8.9. Hogyan is működnek az OS funkciók? . . . . . . 8.9.1. Tipikus mikrokernel (alap)funkciók . . . . 8.9.2. Mikrokernel . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
20 21 22 22 23 24 24 25 25 25 26 26 27 27 27 28 28 28 28 29 29 29 30 30 30 31 31 31
9. Szálak 9.1. Felhasználói szálak . . . . 9.1.1. Signal-ok kezelése . 9.2. Kernel szálak . . . . . . . 9.2.1. Mennyire „olcsó”? . 9.3. Hibrid szálak . . . . . . . 9.3.1. Adatok, struktúrák 9.4. További szál-megoldások? 9.5. Szálműveletek . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
31 33 33 34 34 34 35 36 36
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
3
. . . . . . . .
10.Ütemezés 10.1. Folyamatok ütemezése . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.1. Hosszú távú ütemezés . . . . . . . . . . . . . . . . . . . . . 10.1.2. Közép távú ütemezés . . . . . . . . . . . . . . . . . . . . . . 10.1.3. Rövid távú ütemezés . . . . . . . . . . . . . . . . . . . . . . 10.2. Algoritmusok jellemzői . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.1. Folyamat megszakíthatósága (preemptive) . . . . . . . . . . 10.2.2. Prioritások alkalmazása . . . . . . . . . . . . . . . . . . . . 10.2.3. A döntés alapja . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.4. Vizsgált algoritmusok összehasonlítása . . . . . . . . . . . . 10.2.5. FCFS (FIFO) . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.6. Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.7. Shortest Process Next . . . . . . . . . . . . . . . . . . . . . 10.2.8. Shortest Remaining Time . . . . . . . . . . . . . . . . . . . 10.2.9. Highest Response Ratio Next . . . . . . . . . . . . . . . . . 10.2.10.Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.11.Lottó algoritmus . . . . . . . . . . . . . . . . . . . . . . . . 10.3. Az ütemezők fejlődése . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1. Ütemezés többprocesszoros rendszerekben - szemcsézettség 10.4. Folyamatok és processzorok összerendelése . . . . . . . . . . . . . . 10.4.1. Kernel folyamatok és processzorok összerendelése . . . . . . 10.4.2. Egyes CPU-k multiprogramozása (statikus összerendelésnél) 10.4.3. Folyamatok és szálak ütemezése . . . . . . . . . . . . . . . . 10.4.4. Szálak ütemezése . . . . . . . . . . . . . . . . . . . . . . . . 10.4.5. Szálak üzemezésének módjai . . . . . . . . . . . . . . . . . 10.5. Valós idejű ütemezés (általános célú OS-ek esetén) . . . . . . . . . 10.5.1. Valós Idejű OS-ek jellemzői . . . . . . . . . . . . . . . . . . 10.5.2. Valós idejű OS tulajdonságok . . . . . . . . . . . . . . . . . 10.6. Valós idejű ütemezési megoldások . . . . . . . . . . . . . . . . . . . 10.7. Ütemezési példa – klasszikus Unix . . . . . . . . . . . . . . . . . . 10.7.1. Folyamatok prioritása . . . . . . . . . . . . . . . . . . . . . 10.7.2. Prioritás számítása . . . . . . . . . . . . . . . . . . . . . . . 10.8. Ütemezési példa – Unix SVR4 . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36 36 36 37 37 38 38 38 38 38 39 39 40 40 41 41 42 42 43 43 43 43 43 43 43 44 44 44 45 45 45 46 46
11.Mikor nem csak egy folyamat... 11.1. Signalok . . . . . . . . . . . . . 11.2. Pipe . . . . . . . . . . . . . . . 11.3. FIFO (named pipe) . . . . . . . 11.4. Üzenetsorok . . . . . . . . . . . 11.5. Osztott memória . . . . . . . . 11.6. Szemaforok . . . . . . . . . . . 11.7. Memóriakezelés . . . . . . . . . 11.7.1. Áthelyezhetőség . . . . 11.7.2. Védelem . . . . . . . . . 11.7.3. Megosztás . . . . . . . . 11.7.4. Logikai szervezés . . . . 11.7.5. Fizikai szervezés . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
46 47 47 47 47 48 48 48 48 49 49 49 49
. . . . . . .
49 49 49 50 50 50 51 51
12.Memóriakezelés 12.1. „VM előtti idők” . . . . . . . . 12.2. Lapozás előtti megoldások . . . 12.2.1. Fix Particionálás . . . . 12.2.2. Dinamikus particionálás 12.2.3. Buddy algoritmus . . . 12.3. Áthelyezés kérdésköre . . . . . 12.3.1. Áthelyezési megoldás . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . . 4
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
12.4. Lapozás (egyszerű) . . . . . . . . . . . . . . 12.4.1. Lapok összerendelése . . . . . . . . . 12.4.2. Megoldás jellemzői . . . . . . . . . . 12.4.3. Szegmentálás . . . . . . . . . . . . . 12.4.4. Következmények . . . . . . . . . . . 12.5. Virtuális memóriakezelés . . . . . . . . . . . 12.5.1. VM működés . . . . . . . . . . . . . 12.5.2. Lapozás . . . . . . . . . . . . . . . . 12.5.3. Szegmentálás és lapozás . . . . . . . 12.6. OS szintű kérdések . . . . . . . . . . . . . . 12.7. Algoritmusok – tervezési tér . . . . . . . . . 12.7.1. Betöltési (fetch) politika . . . . . . . 12.7.2. Elhelyezési (placement) politika . . . 12.7.3. Csere (replacement) politika . . . . . 12.7.4. Rezidens lapok kezelése . . . . . . . 12.7.5. Laptisztítási politika . . . . . . . . . 12.7.6. Terhelés szabályozás . . . . . . . . . 12.8. Windows VM kezelés . . . . . . . . . . . . . 12.9. Unix VM kezelés . . . . . . . . . . . . . . . 12.9.1. Unix lapcsere algoritmus . . . . . . . 12.9.2. Memória menedzsment paraméterek 12.9.3. Swapping . . . . . . . . . . . . . . . 12.9.4. Kernel memória menedzsment . . . . 13.I/O kezelés 13.1. I/O eszközök jellemzői . . . . . . . 13.1.1. Adatátviteli sebesség . . . . 13.1.2. Felhasználási mód (terület) 13.1.3. További jellemzők . . . . . 13.2. I/O szervezés lehetőségei . . . . . . 13.3. Operációs rendszer elvárások . . . 13.4. I/O funkciók logikai struktúrája . . 13.5. I/O Pufferelés . . . . . . . . . . . . 13.5.1. Egyszeres puffer . . . . . . 13.5.2. Dupla puffer . . . . . . . . 13.5.3. Cirkuláris pufferek . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
14.Diszk I/O 14.1. Diszkek teljesítményének elemei . . . . . 14.1.1. Idők, értékek . . . . . . . . . . . 14.2. SSD . . . . . . . . . . . . . . . . . . . . 14.3. Diszk ütemezés . . . . . . . . . . . . . . 14.3.1. Diszk ütemezési algoritmusok . . 14.4. Diszk cache . . . . . . . . . . . . . . . . 14.5. RAID . . . . . . . . . . . . . . . . . . . 14.5.1. RAID-0 . . . . . . . . . . . . . . 14.5.2. RAID-1 . . . . . . . . . . . . . . 14.5.3. RAID-3 . . . . . . . . . . . . . . 14.5.4. RAID-4 . . . . . . . . . . . . . . 14.5.5. RAID-5 . . . . . . . . . . . . . . 14.5.6. További RAID szintek . . . . . . 14.5.7. Egyéb források RAID szintekről .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
5
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
52 52 53 54 54 54 54 55 55 55 55 56 56 56 62 63 64 64 64 64 65 65 65
. . . . . . . . . . .
65 65 66 66 66 66 66 67 67 67 67 67
. . . . . . . . . . . . . .
68 68 68 69 69 70 70 70 71 72 72 73 73 74 74
15.Fájlok, fájlrendszerek 15.1. Fájl menedzsment rendszer elvárások . . . . . 15.2. Másodlagos tároló menedzsment tervezési tere 15.3. Fájlrendszer architektúra . . . . . . . . . . . 15.3.1. Rétegek . . . . . . . . . . . . . . . . . 15.3.2. Unix I/O (klasszikus) . . . . . . . . . 15.4. I/O eszközök a fájlrendszerben . . . . . . . . 15.5. Unix I/O . . . . . . . . . . . . . . . . . . . . 15.6. A közelmúlt (90-es évek) Unix fájlrendszerei . 15.6.1. Fájlrendszer keretek . . . . . . . . . . 15.6.2. Több fájlrendszer – a kezdetek . . . . 15.6.3. Fájlrendszerek . . . . . . . . . . . . . 15.6.4. Az s5fs . . . . . . . . . . . . . . . . . 15.6.5. Berkeley FFS . . . . . . . . . . . . . . 15.6.6. Speciális fájlrendszerek . . . . . . . . 15.6.7. Tradicionális fájlrendszerek korlátai . 15.7. Naplózás (journaling) . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
74 75 75 76 76 77 77 77 77 78 78 79 79 80 80 81 81
16.Egyéb témakörök 16.1. Adatmentés módszerei (backup) . 16.2. FUSE . . . . . . . . . . . . . . . 16.3. ZFS . . . . . . . . . . . . . . . . 16.3.1. Copy-on-write . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
81 81 82 82 82
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
6
1.
Mi az operációs rendszer? • An operating system (OS) is a computer program that manages the hardware and software resources of a computer. At the foundation of all system software, the OS performs basic tasks such as controlling and allocating memory, prioritizing system requests, controlling input and output devices, facilitating networking, and managing files. It also may provide a graphical user interface for higher level functions. It forms a platform for other software. (Wikipedia) • Master control program in computer: the essential program in a computer that maintains disk files, runs applications, and handles devices such as the mouse and printer (MSN Encarta) • Olyan program, amely közvetítőként működik a felhasználó és a számítógép hardvere között (KóczyKondorosi, 2000) • A számítógép hardver elemei és az (alkalmazói) programok közötti szoftver réteg, amely biztosítja a hardver komponensek (erőforrások) hatékony használatát. • Az operációs rendszer elfedi a hardver sajátosságait, egyfajta virtuális gépként jelenik meg a felsőbb rétegek számára. • „Ahhoz, hogy elmagyarázzam mi a Linux, el kell magyarázzam, mi az az operációs rendszer. És az operációs rendszer meg olyan valami amivel a felhasználó sosem találkozik. Mert... valójában senki sem az operációs rendszert használja, hanem az emberek egyszerűen programokat futtatnak a gépeken. És az operációs rendszer egyetlen feladata, hogy elősegítse ezen programok futtatását. Tehát az operációs rendszer sosem csinál semmit saját magában, csak várja, hogy a programok adatokat kérjenek tőle, vagy a programok kérik, hogy egy adott fájlt a lemezről beolvasson, vagy más programokon keresztül a külvilághoz kapcsolódjon. És ekkor jön az operációs rendszer, próbálja tenni a dolgát, segítve a programozók munkáját.„ (Linus Torvalds, Revolution OS, felirat/fordítás:
[email protected])
1.1.
Black-box leírás
Nem érdekel, „mi van belül”, az interfészek megadásával írom le a vizsgált „valamit”.
1.2.
Felhasználói interfész
Ember-gép kapcsolata, tipikus formájában képernyő, billentyűzet és (manapság) valamilyen pozicionáló eszköz segítségével. A különféle felhasználói csoportok (végfelhasználó, programozó, rendszer admin) elvárásai eltérőek, ez a különbség általában az interfészben is tapasztalható.
1.3.
Felhasználói csoportok
• Végfelhasználók: Napi tevékenységükhöz szükséges alkalmazásokat használnak, operációs rendszerrel minimális a közvetlen kapcsolatuk. 7
• Fejlesztők (alacsony szintű megoldások): Operációs rendszer által biztosított virtuális gépen fejlesztenek, operációs rendszeri eszközöket (is) használnak (utility-k). • Rendszer adminisztrátorok: Operációs rendszer működését felügyelik, hangolják, folyamatos állapot információkkal kell rendelkezniük, továbbá a működésbe is beavatkoz(hat)nak.
1.4.
Felhasználói felületek
Grafikus és karakteres felületek egyaránt használatosak, egy rendszernek lehet többféle felülete is. A karakteres felület lehet parancssoros és menü alapú is. A végfelhasználók esetén szinte csak grafikus felület, de a többi csoportban is használják. Feladatok összekapcsolása sokszor hasznos lehet, ez jellemzően parancssoros megoldásoknál használatos.
1.5.
Alkalmazási Programozói Felület
Az operációs rendszer, mint virtuális gép „utasításkészlete” (a számítógép utasításkészletének kiterjesztése). Tipikusan rendszerhívásokon keresztül érhető el. A programozói nyelvek tipikusan elfedik ezt a felületet (még a C is – hiszen itt is C függvényhívásokat, nem pedig rendszerhívásokat használunk), de a saját szolgáltatáskészletüket erre alapozzák.
1.6.
Hardver Interfész
Különféle hardver elemek kezelése: hatékonyság, hardverek sokaságának támogatása, képesség a fejlődésre (új fajta hardverek) és hibakezelés.
1.7.
2. 2.1.
Interfészek, határok
Operációs rendszerek fejlődése Operációs rendszer nélkül
A kezdeti idők (40-es évek végétől az 50-es évek közepéig) teljesen manuális megoldás: kézi ütemezés (foglalási tábla) – lehet, hogy programot ki kellett lőni, de az is lehet, hogy a gép „üresen állt”. A program indítása jelentős időt vett el a hasznos működéstől. Feladat: rendszer kihasználtságának növelése. 8
2.2.
Egyszerű kötegelt feldolgozás
50-es évek közepe, GM (IBM platformra). A rendszer vezérlése nem manuálisan, hanem egy program által (rezidens monitor) történik, a futtatandó program kártyáit a monitornak szóló leírással (JCL) együtt előre be kellett „tárazni”. A megvalósítás feltételei: Memória védelem (monitor meg tudja védeni magát), időzítő (timer) később megszakítások, privilegizált utasítások (monitor megkerülése ellen) és végrehajtási módok (user, kernel) megjelenése.
2.3.
Multiprogramozott kötegelt feldolgozás
60-as évek közepétől beszélhetünk multiprogramozott kötegelt feldolgozásról. A kötegelt feldolgozás nem segített a processzor futás közbeni üresjáratain (I/O-ra várakozás). Egy időben több program található a memóriában, ezek közül választjuk ki azt, amelyik futhat. Feltételek: memória menedzsment (több program a memóriában) illetve megszakítások.
2.4.
Időosztásos rendszerek
A kötegelt rendszerek bizonyos feladatokra (pl. tranzakció feldolgozás) alkalmatlanok, viszont a számítógépek túl drágák, hogy egyetlen ember használja őket, ezért az interaktív felhasználók (programjaik) időszeleteket kapnak. Egyik első megvalósítás: CTSS, MIT 60-évek eleje. Ide kapcsolódik a terminálok elterjedése. „A computer terminal is an electronic or electromechanical hardware device that is used for entering data into, and displaying data from, a computer or a computing system.„ (Wikipedia, http://en.wikipedia.org/wiki/Computer_terminal)
2.5.
Kötegelt vs. időosztásos Kötegelt feldolgozás
Időosztásos feldolgozás
Optimalizálás alapja
Processzor kihasználtság maximalizálása
Válaszidők minimalizálása
Rendszer vezérlése
JCL nyelvű programok
Terminálból ad-hoc módon bevitt parancsok
2.6.
Személyi számítógépek
Olcsó, tömegesen elterjedt rendszer, kifejezetten személyi (single user) használatra. Kezdetben korlátos erőforrások, de ma már nem. Az erőforrások kihasználása nem szempont, felhasználói élmény fokozása a cél. A felhasználók informatikai képzettsége sokkal alacsonyabb, mint a korábbi rendszereknél.
2.7.
Valós idejű rendszerek
Nem új történet, de korábban csak specializált területeken használták. Megkülönböztetünk „hard” és „soft” rendszreket, a közkedvelt rendszerek gyakorlatilag csak az utóbbi kategóriát teljesítik. Hard real-time rendszerek esetén komoly matematikai háttér.
2.8.
Elosztott rendszerek
A szükséges számítási teljesítményt és/vagy megbízhatóságot nem drága, egyedi rendszerekkel, hanem több (sok) olcsó rendszer együttműködésén alapuló megoldásokkal biztosítjuk. Igazán kényelmes használatuk újfajta operációs rendszereket (is) igényelne, ezek azonban még inkább csak kutatási fázisban találhatók meg. Feladatokat jelenleg alkalmazás és/vagy middleware szinten oldjuk meg.
2.9.
PDA-k, telefonok, beágyazott rendszerek
A „klasszikus” számítógépektől eltérő használati mód, eltérő hardver képességekkel (perifériák képességei, rendelkezésre álló erőforrások) jellemzik. Méret, fogyasztás sokszor kritikus. Itt is vannak operációs rendszerek: Android, iOS, Windows Mobile, Linux verziók, FreeRTOS.
9
2.10.
„Hol a helyük”?
2.11.
Van még tovább?
Van, mindkét irányban, de ez már kívül esik a tantárgy tárgykörén.
3.
Operációs rendszerek és a hardver
3.0.1.
Hardver
Néhány szó a hardverről: • Processzor – Utasítások végrehajtása (utasításkészlet) – Utasítások forrása: központi memória – Regiszterek (általános célú, státusz és vezérlő) – További adatok tárolása: központi memória – Megszakítások (hardveres és szoftveres) • Memória – Utasítások és adatok tárolása – Stack terület – RAM és NVRAM (ROM) részek • I/O 10
– Típusok ∗ Másodlagos tároló ∗ Humán interfész ∗ Gép-gép kapcsolat – Szélsőséges sávszélesség igények
3.1.
Nincs operációs rendszer
Mivel nincs operációs rendszer, így szolgáltatásokat sem nyújt a programok számára! A rendszer indításakor a program feladata az inicializálás: (Legalább részben) NVRAM-ból kell futnia, CPU beállítások (opcionális), perifériavezérlő áramkörök inicializálása. A program teljess kontrollal rendelkezik az összes hardver elem felett (beleértve a processzort is). Értékelése: Processzor, memória, I/O kezelése is teljes mértékben egyéni megvalósítás, védekezés hibás, rosszindulatú kódoktól: amit a programozó beépít, nincsenek „társak” (csak önmagától kell megvédenie magát). Környezet változására való érzékenység: amit a programozó beépít (jellemzően rendkívül nagy lehet).
3.2.
Minimál operációs rendszer
Rendszer indítás és inicializálás már nem a program feladata. Minimális parancs interfész (CLI, batch), loader funkció, program lehet másodlagos tárolón vagy távoli helyen (tftp). A betöltés után a vezérlés alapvetően a programnál van. Opcionálisan: sokat használt funkciók megvalósítása (kezdetleges virtuális gép!). A perifériák kezelése tipikusan megszakítás alapon történik. Értékelése: Processzor, memória, I/O kezelése továbbra is egyéni megvalósítás, esetleg I/O esetén minimális támogatás (kb. instant eljárások). Védekezés a hibás, rosszindulatú kódoktól: amit a programozó beépít, nincsenek „társak”, az OS védtelen a programtól (MS DOS éra). Környezet változására való érzékenység alapvetően nagy, de mértéke az „instant eljárások” segítségével csökkenthető.
3.3.
A „minimál OS” világán túl: Multiprogramozott rendszerek
A rendszer egyetlen program általi kisajátítása nem „szerencsés”. Régen, mert drága volt a számítógép idő: kötegelt esetben egyetlen program általában nem tudja folyamatosan kihasználni a rendszer erőforrásait (pl. I/O-ra vár), időosztásos rendszernél a számítógépek túl drágák voltak ahhoz, hogy egy időben egyetlen ember használja őket. Ma: hatékonyság, a PC felhasználók szeretnek egyszerre több dologgal foglalkozni, a szervereknek meg egy időben több kliens kérését is ki kell, hogy szolgálják (ezért szerverek). Egy időben több kód fut (látszólag vagy valóban), a programok versenyeznek a számítógép erőforrásaiért (processzor, memória, I/O). A kódok az operációs rendszerre, egymásra és önmagukra is veszélyt jelenthetnek. 3.3.1.
Több program egyidejű futtatása
Kötegelt rendszerek esetén a rendszer terhelését maximalizáljuk. Interaktív rendszerek esetén a válaszidőt kell kordában tartani, a programok között periodikusan kell váltani (a felhasználók egymást nem akadályozhatják). Szerverek: itt is fontos a válaszidő, de nem közvetlen felhasználói interakcióban, hanem gép-gép szolgáltatásban, míg PC-k esetében egy felhasználó több programjára igaz. 3.3.2.
Váltás programok között
Programok közötti váltás: „ki birtokolja” a processzort? (ütemezés). A (vissza)váltás után a program a futását ott folytassa, ahol korábban abbahagyta (hasonlót már láttunk a megszakításoknál). A processzor birtoklásán túl egyéb problémák is adódnak: memóriakezelés, I/O kezelés. Memóriakezelés A processzor csak a központi memóriában található kódhoz/adathoz fér hozzá közvetlenül. A programok (adatok) folyamatos mozgatása a másodlagos tárolóról/tárolóra jelentős erőforrás és időigényt jelentene, ami alatt a processzor semmittevésre kényszerül. Egy időben több programot kell a memóriában tartani, ezért egyetlen program sem sajátíthatja ki a memóriát. A memóriamenedzsment az operációs rendszer feladata, meglehetősen összetett probléma (foglalási módok, relokáicó). 11
I/O kezelés Minden programnak úgy kell „éreznie”, hogy csak „övé a gép”, interferencia nem lehetséges. Az operációs rendszernek kell felügyelnie az I/O kezelést úgy, hogy a programoknak ne kelljen egymással törődniük (megosztható és nem megosztható erőforrások, nem megosztható erőforrás megoszthatóvá tétele). Ha az operációs rendszer nem eléggé „szigorú”, az egész rendszer hatékonysága múlhat az egyes programok „ jólneveltségén” (pl. azonnal visszaadják-e a vezérlést, ha már nem kell nekik). 3.3.3.
Védelem
Az operációs rendszernek meg kell védenie magát és a programokat „egymástól”. Ehhez kell a memória védelme, kontroll memória műveletek (címek) alapján és bizonyos utasítások letiltása a programnak (pl. amivel a memória védelmet lehet befolyásolni vagy perifériához hozzáférni). Ezt hardver támogatás nélkül nem lehet hatékonyan megoldani (esetleg emulációval, ami viszont lassú). Szükséges tehát memória védelmi rendszer, legalább kétféle CPU üzemmód: privilegizált az OS és „normál” a user kód számára (korlátozott), valamint átjárás a két mód között (szoftver megszakítások). 3.3.4.
Operációs rendszeri szolgáltatások
Virtualizáció, az eredeti utasításkészlet kibővítése, elsődlegesen I/O menedzsment (most). Logikai perifériák: másodlagos tároló ( fájlok, fájlrendszerek), humán interfész (input/output csatornák), gép-gép kapcsolat. Az absztrakciós szint eltérő lehet. 3.3.5.
Multiprogramozott OS értékelése
Processzor, memória, I/O kezeléséhez virtualizált környezet. Védekezés hibás, rosszindulatú kódoktól azáltal, hogy a folyamatok csak a saját címterükben futhatnak (önmagukat igen, másokat nem károsíthatnak). Viszont az élet nem ennyire egyszerű: nem megfelelő (védelmi) rendszerbeállítások és a hibák végett. Környezet változására való érzékenység alapvetően az operációs rendszer szintjén jelentkezik, valós és virtuális erőforrások minél teljesebb szétválasztása. Ha az OS nem kezeli a változást, alkalmazás szintről nem (vagy nagyon nehezen) lehet rajta segíteni.
3.4.
Miért hibás, késik?
A funkciók bővülése, a támogatandó hardverek körének bővülése az operációs rendszerek komplexitásának jelentős növekedését eredményezte. Az egyik első időosztásos rendszer, a CTSS (1963, MIT) 32 000 utasításból állt, az egy évvel később bemutatott OS/360 (IBM) mérete már 1 millió+ sort tartalmazott, 1975-re a Multics rendszer mérete meghaladta a 20 millió programsort. Az NT 4 mérete 16 millió+ sor, a Windows 2000 ennek több, mint kétszerese volt, míg azttől a kezdetben kicsi és egyszerű Unix mai mérete sem marad el. A Linux mérete is jelentősen növekedett a kezdetekhez képest. 3.4.1.
A méret következményei
Nehezen menedzselhető a fejlesztés, a kiadások jellemzően késnek, a rendszerben mindig vannak hibák, a javítások (bizonyos hibák megszüntetésén túl) nem egyszer újabb hibákat generálnak, a teljesítmény sokszor nem éri el az elvárt szintet és a rendszer sérülékeny (biztonsági fenyegetések). Ezek miatt a rendszer struktúrája fontos kérdés! 3.4.2.
A változás mozgatórugói
Meglévő kód javításán, optimalizálásán túl... • a funkcionalitás – fájlrendszer funkciók (locking, quota, ACL) – hálózati szolgáltatások – snapshot (fájlrendszer) • a teljesítmény, hardver fejlődése 12
– új hardver-technológiák ∗ RAID ∗ SMP: Uniprocesszoros rendszerekben több program egyidejű futtatása látszólagos, egy időpillanatban egy aktív program van (ez lehet oprendszer kód is). Multiprocesszoros esetben valós párhuzamosság jelenik meg, ami jelentősen bonyolítja a működést. ∗ NUMA: a „hagyományos” memóriák elérési ideje címfüggetlen, amit ki is használunk a memória kezelő megoldásokban. A NUMA rendszerekben viszont nem. – új hardver eszközök, családok támogatása – teljesítmény jellemzők változása ∗ SSD: a „hagyományos” diszkek esetén az átvitel helyfüggő (fejmozgások), amelyekkel a különféle algoritmusok számolnak. Az SSD-k esetében nincs mozgó alkatrész. ∗ vagy abszolút változás: hálózat 10Mbit/s-ről 1Gbit/s-re (és tovább), szalagok (1999 DLT: 3MB/s, 2007 LTO-4: 120MB/s) – eszközök egymáshoz képesti teljesítményének változása • a minőségi elvárások, megbízhatóság – adatvesztés rendszerösszeomlás esetén – helyreállási idő (hiba után) – működés hibák során • és a paradigmaváltás, új alkalmazások – kliens-szerver alkalmazások – szálak – real-time elvárások (pl. média szerverek) • valamint a felhasználói élmény és a versenytársak jelentik a változás fő mozgatórugóit.
4.
Unix történelem
1969, AT&T Bell labs: alig használt PDP-7 „a sarokban” áll a Multics projekt leállítása után. (Space travel játék - Thompson). A PDP-7 gépen nem volt fejlesztő környezet (cross compilert kellett használni), ezért Thompson, Ritchie és mások elkezdtek írni egyet (először a fájlrendszert, majd jött a process alrendszer és egy egyszerű shell). „Multics (Multiplexed Information and Computing Service) was an influential early time-sharing operating system. The project was started in 1964 in Cambridge, Massachusetts. The last known running Multics installation was shut down on October 30, 2000, at the Canadian Department of National Defence in Halifax, Nova Scotia, Canada.„ (Wikipédia, http://en.wikipedia.org/wiki/Multics) Thompson, Ritchie és Ossanna meggyőzi a BTL-t hogy vegyenek egy PDP-11 gépet szövegszerkesztésre. A Unix portolásra kerül, majd megszületnek az első egyszerű kiadvány szerkesztő programok. Thompson a BCPL nyelvből kiindulva kifejleszti az interpretált B nyelvet, ennek alapján – Ritchie által – megyszületik a C nyelv. A Unix diadalútja C nélkül nem valószínű, hogy bekövewtkezett volna, (és viszont). „Bell Laboratories (also known as Bell Labs and formerly known as AT&T Bell Laboratories and Bell Telephone Laboratories)„ (Wikipédia, http://en.wikipedia.org/wiki/Bell_Labs) A rendszer a BTL-en belül közkedveltté válik, de házon kívül nem ismerik. 1973-ban kiadott (belső) verzió már tartalmazza a „cc” C fordítót. Ugyanebben az évben az egész rendszert újraírják C-ben – ez a lépés alapozza meg a későbbi sikert. 1973-ban a Unix bemutatása egy ACM konferencián (1974, első írott publikáció). Az 1956-os antitröszt határozat miatt az AT&T nem kereskedhetett számítástechnikai termékkel (sem), ezért az ACM konferenciát 13
követő nagy számú megkeresés hatására az AT&T a rendszert kutatási és (egyetemi) oktatási célokra jogdíj nélkül átadta (forráskóddal együtt). 1975-ben már telepített Unix-ot találunk Kanadában, Izraelben és Ausztráliában is, a Berkeley egyetem az elsők között kap Unix licencet (1974 decemberében). A gyors terjedés mellett megkezdődnek a módosítások (forráskód elérhető), az eredményeket sokszor a BTL is beépíti saját fejlesztéseibe. A Berkeley-en különösen aktív fejlesztés folyik, az eredeti rendszert jelentősen jobbító programokat külön csomagban, pénzért (USD50) kezdik forgalmazni. 4.0.3.
A BSD Unix
Először itt készül virtuális memóriakezelés Unix-hoz (32 bites VAX gépre). 1979-ben pedig megjelenik az első saját OS verzió (3BSD) – ez már teljes csomag. A DARPA támogatja a Unix továbbfejlesztését (VM és TCP/IP fejlesztés), ezeken kívül még több jelentős újítás is onnan származik. 1993-ban megjelenik az utolsó (4.4BSD) verzió, a fejlesztés befejeződik. A rendszert a BSDI viszi tovább, a történet rögtön egy AT&T perrel indul – 1994-től érhető el a 4.4BSD-lite. Azonban a fejlesztés a Bell berkein belül sem áll le, 1982-ben az AT&T beléphet a piacra. Időközben a Unix Support Group nevű csapat kiadja a System III verziót (1982), majd 1983-ban a sokkal agresszívebben marketingelt System V-t. Sok kommerciális Unix alapul valamelyik System V verzión, a jelenlei verzió az SVR4. Több cég is foglalkozott saját hardverére portolt (és kibővített) Unix forgalmazásával (ezek forrása vagy a BTL vonal, vagy a BSD volt). Az első cég Ineractive Systems 1977-ben, de a Microsoft (az SCO-val együttműködve) is az elsők között van. 1982-ben Bill Joy kilép a Berkeley-ről és másokkal együtt megalakítja a Sun Microsystems céget. Rendszerük a SunOS a 4.2BSD-n alapul. A 80-as években több gyártó (IBM, HP, DEC és mások) is előrukkol saját új gépeivel és ehhez saját Unix verziót adnak ki. Minden cég megpróbál egyre több extra szolgáltatást beépíteni a rendszerébe, ez gyors fejlődést eredményez, ugyanakkor a különféle Unix verziók többé-kevésbé inkompatibilisek egymással. 4.0.4.
Mach
A Unix születéskori erősségei – kis méret és egyszerűség – az egyre több és több szolgáltatás beleintegrálásával tovatűntek. A 80-as évek elején a pittsburgi Carnegie-Mellon egyetemen megkezdődött egy új, mikrokernel alapú operációs rendszer – a Mach – fejlesztése. A rendszer „kívülről” BSD interfésszel bírt, ugyanakkor AT&T kódtól teljesen mentes volt. A 2.5-ös (még monolitikus kernelű) verzió több piaci rendszer (OSF/1 és NextStep) alapja lett, az első mikrokerneles verzió a 3.0 volt.
4.1.
A Unix háború
1987-ben az AT&T szövetkezett a Sun-nal a következő System V verzió (SVR4) kidolgozására (a Sun korábban BSD vonalat használt). Megjelenik a Solaris 2. Ez a lépés az iparban komoly nemtetszést váltott ki, így kezdetét vette a Unix háború. Szövetségek alakultak és szűntek meg, de egy új fenyegetés – a Windows NT – mindent megváltoztatott.
4.2.
A közelmúlt
A Unix név és kód a Novell-hez kerül, 1993-ban a Novell a Unix márkanevet és a minősítés jogát átadja az X/Open konzorciumnak, a kódot pedig az SCO-nak, 2000-ben az üzletág a Caldera-hoz kerül, neve SCO Group lesz. Az SCO a Linux szállítókat (IBM) és felhasználókat támad szellemi tulajdon megsértéséért (a perbe a Novell is belép, végül az SCO nem jár sikerrel). A gyakorlatilag csak papíron létező SCO később (2011) az unXis kezébe kerül. Sok, a 80-as években virágzó gyártó eltűnik, a megmaradtak (IBM, HP) viszont továbbra is fejlődnek – a Unix él és virul. A Sun, mint egyik meghatározó szereplő 2009-ben az Oracle kezébe került, de ennek hosszabb távú kihatásai ma még nem láthatók. A Solaris továbbra is fejlődik... (OpenSolaris, Illumos nyílt projektek)
4.3.
Szabványok
A sokféle verzió megkeserítette a fejlesztők életét, ezért szabványosítási törekvések kezdődtek, de szabványból is sok, különböző alakult ki (ezek nem a belső működést, hanem az interfészeket írják le). Egyik legjelentősebb szabvány az IEEE POSIX specifikáció. A szabványos kód nem tartalmazhatja az adott platformra jellemző többlet funkciókat! 14
4.4.
Összefoglalva
Kezdetben az akadémiai szektorban sikeres. Forráskód elérhetősége (feltételekkel) miatt, sok változat, ami visszahat a „fő” kódra is. Sok neves gyártó jelentet meg saját, üzleti alapú verziót, ez inkompatibilitáshoz vezetett, ami ellen a különféle szabványok (pl. POSIX) próbálnak védekezni. Léteznek olyan rendszerek, amelyek csak interfész szinten Unix-ok (Mach, Mac OS, Linux). Az idők során a Unix forrás is jelentősen átalakult (SVR4).
15
4.5. 4.5.1.
Solaris – példa az „új” Unix-ra Klasszikus (pre. SVR4) kernel
16
4.5.2.
„A Solaris előtt”
1982-ben megjelent a SunOS 1.0 – BSD 4.1 alapú, még Motorola 68000 alapú Sun gépre, tartalmaz több hálózati technológiákat ért komoly fejlesztést, több széles körben elterjedt (NFS, RPC). Az implementálásuk jelentős módosítást igényelt, a SunOS 2.0 már tartalmazza VFS-t (1984). 1988-ban SunOS 4, új VM, dinamikus linkelés, ez az első SPARC alapú rendszer. Multiprocesszoros rendszerek támogatása, a SunOS 4.1 esetén még aszimmetrikus módon, a szimmetrikus multiprocesszing nagyon más... 4.5.3.
„Solaris 2 és azon túl”
Az AT&T szövetség hatására a Sun System V alapon teljesen új rendszerrel ál elő. Ez volt az 1992-ben megjelent Solaris 2.0 – még csak uniprocesszoros, de még ebben az évben multiprocesszoros támogatás (2.1). 1993-tól megjelenik az x86 platform támogatás. 1996-ban már 64 utas SMP (2.5.1) , ugyanekkor fájlméret max. átlépi a 2GB-t (2.6) – FS 2.2 óta nagyobb. Következő nagy lépés a Solaris 7 (nem 2.7), ami már 64 bites processzorokat is támogatja. Minden verzió hoz újításokat (RBAC, újabb ütemezők, zónák és x64 támogatás), Jelenlegi verzió az Oracle Solaris 11. OpenSolaris (Oracle felvásárlás hatásai?). Támogatott platormok: Sun UltraSPARC alapú rendszerek, Fujitsu SPARC64 platform alapú rendszerek, 32 és 64 bites AMD rendszerk és Intel valamint VIA x86 CPU-k. 4.5.4.
A Solaris 2 kernel
5.
Konszolidáció, virtualizáció
6.
Linux
Születése Linus Torvalds nevéhez kötődik, aki 1991-ben fejlesztette ki 80386 alapú gépre (az University of Helsinki hallgatójaként). A fejlesztés egy terminál emulátor szoftverrel kezdődött (Unix-os nagygépekhez való csatlakozás megoldására), de ez lett belőle... A korai verziót Linus az interneten is közzétette, hamarosan meglehetősen komoly felhasználói tábort szerezve, így a fejlesztés közösségi projektté vált. Ma sokféle disztribúció (terjesztés) létezik, egyes esetekben modifikált kernellel (aktuális „stabil” verzió: 3.3.7) 17
6.1.
verziók
Idővel különféle, egymással többé-kevésbé kompatibilis disztribúciók alakultak ki, ezek közül „kinőtt” néhány kifejezetten üzleti megoldás is. Az üzleti sikerekhez robosztusság, megfelelő funkcionalitás és gyártói támogatás szükséges. A támogatás nagy hardver és szoftver szállítóktól megvan (IBM, HP, Oracle, SAP). „Fizetős” disztribúciók: RedHat, SuSe, míg néhány ingyenes: Debian, Fedora és „sokan mások”.
6.2.
Jellemzők
A Linux jellenzői közé tartozik a POSIX kompatibilis felületek (felhasználói és programozói is), de felhasználói felületen új szabványt teremtett. A moduláris felépítésű kernel (Dynamic linking, Stackable modules), a virtuális fájlrendszer támogatás, és valós idejű ütemezés is.
6.3.
Linux kernel
Moduláris kernel (de nem mikrokernel, hanem monolitikus), fogalmi szinten sok ponton rokonságban van a Unix kernellel, de vannak különbségek (pl. szálak kialakítása). Linux esetében is megvan a kétféle mód: user és kernel mód, eltérő hozzáférési szinttel, s a kernel funkciók rendszerhívásokon keresztül érhetők el.
18
6.4.
Szabványos felületek
A szabványos felületek célja a hordozhatóság (bináris vs. forráskód szinten) biztosítása különféle gyártói megoldások között (Unix), vagy különféle disztribúciók között (Linux). A Linuxban több helyen az „eredeti” Unixtól élesen különböző megoldások vannak, de az interfészek szabányosak. ilyen a POSIX (Portable Operating System Interface for uniX) vagy a Single UNIX Specification (The Open Group). Linux Standard Base (LSB) pedig a különféle Linux disztribúciók által minimálisan támogatandó API-k készlete révén biztosítja az egyes terjesztések közötti kompatibilitást.
7.
Windows
7.1.
A Microsoft „korai” operációs rendszerei
• 1981: PC-DOS 1.0 (flat FS) • 1983: DOS 2.0, XT, HDD támogatás • 1984: DOS 3.0, IBM AT • 1990: Microsoft Windows 3.0 • 386 alapú rendszerek támogatására IBM és MS közös fejlesztés (OS/2) – Összeveszés, NT fejlesztés indul – IBM viszi tovább az OS/2-t, ami soha nem lett átütő siker. Az OS/2 ágat viszi még tovább az eComStation nevű zárt rendszer.
7.2.
Roadmap
A Microsoft „nulláról” fejleszti a saját rendszerét, amely csak felületeiben (GUI, API) hasonlít a Windows 3-ra. 1993-ban az első Windows NT, a 3.1. 1996-ban az NT 4.0 – Win 95 felület (kernel GUI). 2000-ben Windows 2000 (plug-n-play, pwr m., AD), majd 2001-ben megjelenika Windows XP (csak desktop). 2003-ban Windows 2003 server, 64 bit (kezd. IA64). Kurrens rendszerek: Windows 2008, Win 7 (Win 8).
7.3.
Elvárások: 1989
Legyen 32 bites, preemptive, rendelkezzen VM támogatással. Többplatformos működés, jó SMP skálázhatóság, kliens-szerver környezet támogatás, MS-DOS és Win 3.x alkalmazások futtatása (de nem minden áron...). Kormányzati POSIX 1003.1 elvárás, és kormányzati biztonsági elvárások, valamint Unicode támogatás.
7.4.
Célok és jellemzők
Fejlesztési célok közé tartozik a bővíthetőség (piaci elvárások), a hordozhatóság, a megbízhatóság és a robosztusság, a kompatibilitás és a teljesítmény. Jellemzői: valós (preemptive) multitasking, kliens-szerver modell, SMP és szálak támogatása, Objektum alapú megközelítés, illetve nagyrészt C nyelvű kód. 19
7.5.
8.
Kernel
Folyamatok
Programok és erőforrások dinamikus összerendelése folyamatok Tárgyalás időbeli fejlődést követ: egy processzor, nincsenek szálak; több (szimmetrikus) processzor; több szál (több processzoron), majd az operációs rendszeri megvalósítási modellek és a folyamatok és erőforrások összerendelése (CPU, memória, I/O–ütemezések, együttműködés, verseny, problémák). 20
8.1.
Mi a folyamat?
A folyamat a multiprogramozott operációs rendszerek egyik alapfogalma, először a Multics rendszer fejlesztői használták (60-as években), jelentése (egyik): a program végrehajtás alatt álló példánya. A program futásához – legalább az aktuálisan végrehajtandó – utasításoknak és az általuk kezelt adatoknak a memóriában kell lennie. A program futása során több-kevesebb I/O eszközt szeretne használni (írni, olvasni), ezeket az operációs rendszer szolgáltatja a programoknak, ahhoz, hogy a program valóban fusson, a fenti feltételeken (memória, I/O) túl a processzorhoz is hozzáférést kell kapjon.
A folyamat leírható: • Terület a központi memóriában (kód, adat, stack) • Adatok és státuszinformációk a processzor regisztereiben • Egyéb státuszinformációk (pl. erőforrásokkal kapcsolatos) • Egy végrehajtási szál (most éppen melyik utasítást kell végrehajtani) Kiindulás (most): az operációs rendszerek folyamatok szintjén ütemeznek (de már nem...). Folyamat váltáskor a teljes folyamat környezetet meg kell őrizni – ez biztosítja a folytathatóságot!
21
8.2.
Folyamatok állapotai
A folyamatok és a processzorok közötti (dinamikus) összerendelésről az ütemező gondoskodik, a kiválasztást különféle ütemezési algoritmusok végzik. A hatékony ütemezés megvalósítása értekében bevezetjük a folyamatok állapotának fogalmát. A legegyszerűbb modell szerint egy folyamatnak két állapota lehet: (i) Fut, azaz éppen birtokolja a processzort, (ii) Nem fut. 8.2.1.
Kétállapotú modell
Kritika: Nem tudjuk, hogy az éppen nem futó folyamat tudna-e futni egyáltalán.
22
8.2.2.
Három állapotú modell
Kritika: Nem tudjuk, a blokkolt folyamat milyen (melyik) erőforrásra vár!
23
8.2.3.
Három állapotú modell bővítés
Kritika: A folyamat létrehozása és megszün- tetése nem végtelenül rövid tevékenység! 8.2.4.
Öt állapotú modell
24
8.2.5.
Hét állapotú modell
8.2.6.
Valós állapot modellek (Unix)
8.3.
Folyamatok közötti váltás
Oka lehet az időszelet letelte (Aktív –> Futásra kész), blokkolódás I/O miatt (Aktív –> Blokkolt), vagy egyéb (pl. prioritások miatt). Megvalósítás (process switch) a következő lépésekből áll: az éppen futó folyamat összes 25
fontos adatának (környezetének) elmentése, majd a futásra kiválasztott folyamat környezetének visszaállítása és a vezérlés átadása az újonnan kiválasztott folyamatnak. 8.3.1.
Folyamatváltás háttere
A környezet mentés és visszaállítás minden esetben kernel kódot igényel, a váltás során általában a memória táblákat (virtuális memória kezelés) is módosítani kell. A folyamat váltás meglehetősen sok utasítás végrehajtását (CPU ciklus) igényli, ezért „drága” tevékenység! 8.3.2.
Mód váltás
Folyamat váltás során az érintett folyamat állapota megváltozik, másik folyamat lesz aktív (futó). Bizonyos esetekben nem más folyamat, hanem a kernel kell, hogy fusson (pl. IRQ), a folyamat folytatásához szükséges adatok ilyenkor is mentendők, de ez kevesebb, mint a teljes környezet (kevésbé „drága” tevékenység)! Célszerű folyamat váltásról és mód váltásról külön beszélni! Kernel
kód
futtatása
(mód
váltás).
Mód váltás
Folyamat váltás
kernel módba vált kernel által használt adatokat menti címtér nem változik, de kernel címtér elérhető folyamat tovább futhat, státusza nem változik
folyamat minden adatát menteni kell címtér változik a folyamat státusza változik, más folyamat fog futni
26
8.4.
8.4.1.
Folyamatok létrehozása (Windows)
Végrehajtható fájl
Végrehajtható fájl típus
Végrehajtás módja
Windows .exe Win16 .exe MS-DOS .exe, .com, .pif MS-DOS .bat, .cmd POSIX kód OS/2 1.x kód
közvetlenül Ntvdm.exe program Ntvdm.exe program Cmd.exe Posix.exe Os2.exe
8.5.
Folyamatok létrehozása (Unix)
A windowsétól teljesen eltérő megoldás (eléggé fura). A program indítása két részből áll (i) az aktuális folyamat duplikálása (szülő-gyerek) és (ii) az indítandó program betöltése a gyerek folyamat helyére. Sokat kritizált, de a mai napig élő megoldás.
27
8.5.1.
Folyamat duplikálás – fork()
mypid = fork() if(mypid == 0) { // Child printf(“%ld – I’m the parent\n”, getpid()) } else { // parent printf(“%ld – I’m the parent\n”, getpid()) } 8.5.2.
fork() másik példa
int a = 1; int b = 2; if(fork() == 0) { printf(“Gy:\t%d, %d\n”,a,b); a += 2; printf(“Gy:\t%d, %d\n”,a,b); } else { printf(“Sz:\t%d, %d\n”,a,b); sleep(1); printf(“Sz:\t%d, %d\n”,a,b); } Kimenet. • Gy: 1,2 • Sz: 1,2 • Gy: 3,2 • Sz: 1,2 8.5.3.
Fork() működése
A fork() hatására a teljes folyamat címterét és az erőforrás adatokat is duplikáljuk. A duplikálás után a címterek függetlenek, a változók külön élnek, de a kezdőérték ugyanaz. A fájlokat mindkét folyamatból el lehet érni, ha mindkettőből írunk, akkor a kimenet összekeveredve jelenik meg. 8.5.4.
exec()
A fork() érdekes, de hogyan indítunk új programot? Az exec() hívás az éppen futó folyamat „helyére” tölt be (és indít el) egy programot, ekkor a pid nem változik és az erőforrás leírók is öröklődnek (pl. így működik a pipe a shell- ben).
28
8.6.
Folyamat-leírók
Erőforrás menedzsment megvalósításához az operációs rendszernek elegendő információval kell rendelkeznie a folyamatok és az erőforrások mindenkori állapotáról, ezt az OS különböző táblázatok fenntartásával valósítja meg. Tipikus táblázatok: memória tábla (fizikai és VM is), I/O tábla, fájl tábla és folyamat tábla. • Memória tábla (fizikai és VM is) – memória – folyamat összerendelés, – védelmi információk, – VM információk • I/O tábla – Processz információ – Státusz – Memória info (pl. puffer terület) • Fájl tábla – Adattartalma attól függ, hogy a fájlkezelés feladatai milyen módon oszlanak meg az OS és az alkalmazás között • Folyamat tábla A táblázatok függenek egymástól, de hivatkoznak egymásra (pl. fájl és I/O, folyamat és mindegyik). A táblázatokat inicializálni kell, meg kell határozni határértékeket. Ez történhet konfiguráció alapján statikusan vagy dinamikusan.
8.7.
Operációs rendszer végrehajtása
Az operációs rendszer is egy program, amelyet a CPU hajt végre, a teljes rendszer működtetéséért az OS felel, önmagát teljesen nem menedzselheti (tyúk vagy tojás), ezért operációs rendszer végrehajtási modelleket dolgoztak ki. Ilyen a nonprocess kernel, folyamat címterében futó kód és a folyamat alapú kernel. 8.7.1.
Modellek
A nonprocess kernel esetébn kernel szinten nem értelmezett a folyamatok fogalma, a kernel teljesen szeparált, saját törvényei szerint fut. Folyamat címterében végrehajtott kernel kód esetében a kernel nem folyamat alapú, (user) folyamatok címterében fut, minden folyamat címterében elérhető, de a folyamatok nem látják. Folyamat alapú kernel esetében a kernelt is folyamatokként valósítjuk meg (kliens-szerver modell, többprocesszoros rendszeren is hatékony), viszont kell egy folyamat váltási funkció, ami a folyamatok „alatt” fut.
29
8.7.2.
Kernel kód futtatása folyamat címterében
8.7.3.
Folyamat alapú kernel
8.8.
Mikrokernelek – miért?
Operációs rendszerek fejlődése alapján elkülönítjük a teljesen monolitikus kódot (több millió sor), a struktúrált felépítésű, rétegelt kódot és a mikrokerneleket. Miért nem eléggé jó a struktúrált kód? Mert a kernel módban a súlyos hibák végzetesek, nehéz kernel kódot írni és a növekvő funkcionalitás miatt egyre több és több kód kell(ene)!
30
8.9.
Hogyan is működnek az OS funkciók?
Különféle kernel funkciók pl. lapcsere memóriakezelés esetén szükséges a döntés (döntés politika), vagyis lap helyének kiválasztása és maga a végrehajtás, azaz a tényleges lapbetöltés. A végrehajtás tipikusan hardver közeli, de a döntés nem igazán, ezért ha a megfelelő adatok rendelkezésre állnak, a döntési rész akár kernelen kívül is futhat(na). Mikrokernel esetében a kernel csak az alapfunkciókat tartalmazza, a kód többi részét felhasználói módban futó szolgáltatások valósítják meg. Ezen megoldás erősségei az egységes interfész, a bővíthetőség, flexibilitás, hordozhatóság, megbízhatóság, elosztott rendszerek támogatása, és az OO támogatása. 8.9.1.
Tipikus mikrokernel (alap)funkciók
• Alacsonyszintű memória menedzsment • IPC • IRQ kiszolgálás • I/O kezelés (alacsony szinten) 8.9.2.
Mikrokernel
Mikrokernel esetében a kernel csak az alapfunkciókat tartalmazza, a kód többi részét felhasználói módban futó szolgáltatások valósítják meg. Az igazán elterjedt rendszerekben tisztán nem igazán lehet találkozni vele.
Gyenge pontok. Kernel és felhasználói mód közötti váltás erőforrás igényes (lassúság), ezért figyelni kell a kernelbe épített funkciók arányára. Ha túl sok mindent kiszervezünk, akkor sok lesz a váltással járó többletmunka. Teljesen új koncepció, gyakorlatilag nulláról újra kell írni a rendszereket.
9.
Szálak
Programok egyre több párhuzamosan is végrehajtható részfeladattal bírnak: szerver megoldások (web, file); kliensek esetén háttérfunkciók (backup, stb.), előtér párhuzamosítás (pl. web böngésző). A több (sok) processzor kihasználásához párhuzamosan végrehajtható kód kell!. Ezek a kódok nem függetlenek – közös adatok, együttműködés (szinkronizáció)! Természetes megoldás: párhuzamos kód, ehhez több folyamat (hiszen erre való). Ez így jó (is volt sokáig), de létrehozásuk, megszüntetésük drága, a kommunikáció, együttműködés csak (drága) kernel műveletekkel lehetséges és a folyamatok közötti váltás költséges. De általában elmondható, hogy a kernel funkciók futtatása drága! Ezért van szükség a szálakra. 31
Az alapötlet, hogy válasszuk külön az erőforrások birtoklását a program futtatásától! A folyamat az erőforrás foglalás alapegysége (mint eddig is), a szál meg a folyamaton belüli futási végrehajtás egysége. Egy folyamaton belül egyszerre több végrehajtási szál is létezhet.
A folyamathoz képest gyorsabb végrehajtás és terminálás, valamint egy folyamaton belül a szálak közötti váltás gyorsabb, mint a folyamatváltás és a szálak közötti adatcsere, kommunikáció kernel funkciók igénybe vétele nélkül zajlik. De nem a folyamatok helyett van! Megvalósítási lehetőségek: a felhasználói szálak, a kernel szálak és hibrid megoldások.
32
9.1.
Felhasználói szálak
Kernel nem tud róla, továbbra is folyamatokat lát, a szálmenedzsment alkalmazás szintű kóddal (lib) történik, így a szálütemezés folyamatonként eltérő lehet. Előnyei, hogy a szálváltás gyors (user módban fut), az OS-től független, hordozható megoldás. Korlátai, hogy a I/O blokkolhatja az összes folyamat-szálat (aszinkron I/O), 1 folyamat összes szála 1 CPU!, és a Signal-ok kezelése nem triviális. 9.1.1.
Signal-ok kezelése
A signalok aszinkron események (nem szinkron válasz egy hívásra). Felhasználói szálak esetén a kernel csak folyamat szinten tudja ezeket az eseményeket kezelni, így ez is a thread könyvtár problémája.
33
9.2.
Kernel szálak
A teljes szálmenedzsment kernel módban valósul meg, felhasználói szinten csak API van, tehát a szálak ütemezést a kernel végzi. Erősségei, hogy egy szál blokkolódása nem blokkolja a teljes folyamatot, a folyamat szálai több CPU-n is futhatnak és a signal kezelés megoldott, viszont korlátja, hogy drága. 9.2.1.
Mennyire „olcsó”?
1992, VAX-on végzett mérések (UNIX-szerű környezet) UL KL Process Null fork Signal Man
9.3.
34 us 37 us
948 us 441 us
11300 us 1840 us
Hibrid szálak
Például Solaris-ban a Solaris 10 előtt.
34
A felhasználói szálak alkalmazás szinten értelmezettek, de vannak szálak kernel szinten is. A kernel LWP-k (LightWeight Process) szintjén látja a folyamatokat (ezek 1:1-ben kapcsolódnak kernel szálakhoz), az LWP-k és a felhasználói szálak közötti kapcsolatot felhasználói szintű kód menedzseli. A felhasználói szálak és LWP-k aránya dinamikus, de kódból is módosítható. A Solaris 10-ben már nincs meg ez a megoldás! 9.3.1.
Adatok, struktúrák
Kell privát stack (user mindig, kernel szálak esetén kernel stack is), a szálaknak is van állapota (ready, run, blocked) és prioritása, a CPU regisztereket menteni kell: TCB (a PCB-vel analóg módon).
35
9.4.
További szál-megoldások?
Szálak
Folyamatok
Név
1 n 1 m
1 1 n n
Klasszikus (multiprocessing) Több szálas (multithreading) Kísérleti (elosztott rendszerek) Kísérleti
9.5.
Szálműveletek
POSIX threads (felhasználói szintű szálkönyvtár) szolgáltatásai a szálak létrehozása és megszüntetése, az üzenetek és adatok átadása szálak között, a szálak végrehajtásának ütemezése, valamint a szál környezet mentése és visszaállítása.
10. 10.1.
Ütemezés Folyamatok ütemezése
A folyamat ütemezés célja a folyamatok és a processzor(ok) összerendelésének dinamikus szabályozása. Típusai: hosszú távú ütemezés, közép távú ütemezés és rövid távú ütemezés. Ezen felül létezik még I/O ütemezés is. 10.1.1.
Hosszú távú ütemezés
A programok aktiválását szabályozza (folyamat diagramban a „felvesz” állapot átmenetet jelképezi). Biztosítja, hogy a multiprogramozás foka optimális legyen a rendszerben. Szempontok: folyamatok száma a rendszerben, és a CPU passzív (idle) állapotának aránya a teljes CPU időhöz képest.
Megvalósítás Kötegelt rendszerek esetén a job-ok egy várakozó sorba kerülnek, ebből választ a hosszú távú ütemező. A döntés dimenziói: mikor válasszon új folyamatot (multiprogramozás fokának optimalizálása), melyik folyamatot válassza (FIFO vagy terhelési minta optimalizálás). Interaktív rendszerekben viszont a felhasználó a fő ütemező, OS lehetőségei: ha a rendszer terhelése meghalad egy kritikus szintet (ez általában a folyamatok számában, esetleg a szabad virtuális memória mennyiségében mérhető), akkor nem engedi új folyamat létrehozását.
36
10.1.2.
Közép távú ütemezés
Feladata komplett folyamatok mozgatása a központi memória és a másodlagos tároló (swap terület) között (swapping). Vizsgálata a memóriakezelés ismertetése során fog megtörténni.
10.1.3.
Rövid távú ütemezés
Ez az ütemező közvetlenül és folyamatosan meghatározza a processzor(ok) és a folyamatok közötti kapcsolatot. A hosszú- és közép távú ütemezők viszonylag ritkán aktivizálódnak csak durva ütemezési döntéseket hoznak, a rövid távú ütemező aktivizálódásához viszont különböző események vezethetnek (nem mindegyik esemény érvényes minden algoritmus esetén). Ilyenek az időzítő megszakítása, az I/O megszakítások, az operációs rendszer hívások, vagy a signal-ok. Rövid távú ütemezési szempontok Meglehetősen sokféle algoritmus létezik, ám egyik sem „mindenható”. Lehetséges vizsgálati szempontok közé tartozik a felhasználó vagy rendszer orientált, illetve a teljesítmény alapú vagy „egyéb”. Felhasználó vagy rendszer orientált Felhasználó orientált esetben az egyedi felhasználók (folyamatok) igényeit vesszük figyelembe, így például az egyes folyamatok válaszidejét, ezek azok a szempontok, melyeket interaktív rendszer esetén egy felhasználó valóban érzékel. Rendszer szempontjából a rendszernek a kihasználtsági szint maximalizálására kell törekednie, míg az egyes felhasználók (folyamatok) kevésbé érdekesek, ez a felhasználók érdekét sértheti ezért egyszerre mindkét szempontot nem lehet teljesen kielégíteni. Teljesítmény alapú vagy egyéb A közvetlen teljesítmény jellemzők mellett más tényezők is befolyásolják a rendszerről alkotott véleményt, pl.: megjósolhatóság, azaz ha folyamatosan hasonló válaszidőket produkáló rendszer sokkal inkább elfogadható egy felhasználó számára, mint egy folyamatosan ingadozó rendszer (ugyanarra a tevékenységre vizsgálva).
37
Szempontok
Felhasználó orientált
Rendszer orientált
Teljesítmény alapú
Egyéb
-Fordulási idő (B) -Válaszidő (I) -Határidők tartása -Átbocsátóképesség (B) -CPU kihasználtság
-Megjósolhatóság
-Korrektség (Kiéheztetés) -Prioritások biztosítása -Erőforrások kihasználása
B: batch (kötegelt), I: Interaktív
10.2.
Algoritmusok jellemzői
10.2.1.
Folyamat megszakíthatósága (preemptive)
Meghatározza, hogy az ütemező algoritmus megszakíthatja-e egy folyamat futását, vagy az csak akkor szakad meg, ha a folyamat lemond a CPU-ról vagy erőforrás miatt blokkolódik. A megszakítható ütemező algoritmusok általában bonyolultabbak, jobban terhelik a rendszert, ugyanakkor sokkal korrektebb ütemezési megoldást biztosítanak. 10.2.2.
Prioritások alkalmazása
Több olyan algoritmus is van, ahol a folyamatok közötti választást egy, a felhasználó által meghatározott fontossági információ (prioritás) befolyásolja. A „tiszta” prioritásos megoldás fő problémája az alacsonyabb prioritású folyamatok kiéheztetése. 10.2.3.
A döntés alapja
A döntés alapja több paraméter közül kerülhet kiválasztásra: • A folyamat rendszerben eddig eltöltött összes ideje (várakozás és végrehajtás egyaránt): w • Az eddig futással eltöltött idő: e • A folyamat becsült teljes kiszolgálási ideje (az eddig eltöltött időt is beleértve): s • Fontos látni, hogy a kiszolgálási idő valóban csak becsülhető, amely az esetleges múltbéli tapasztalatok alapján pontosítható. A túlzottan optimista folyamatok futását (amelyek az előre megadottnál sokkal tovább kívánnak futni) a megadott idő letelte után a rendsz Vizsgált algoritmusok: FCFS (FIFO), Round Robin, Shortest Process Next, Shortest Remaining Time, Highest Response Ratio Next, Feedback, Lottó ütemezéser megszakíthatja. 10.2.4.
Vizsgált algoritmusok összehasonlítása Kiválasztási funkció
Preemtív?
Átbocsátás
Válaszidő
Overhead
Nem
N.a.
Magas lehet
Minimum
Alacsony, ha a
Rövid folya-
kvantum kicsi
matoknál jó
Hatása a folyamatra
Kiéheztetés
Rövid és I/O FCFS
max[w]
igényes felada-
Nem
tokat bünteti RR
konstans
Időszeletnél
SPN
min[s]
Nem
Magas
SRT
min[s-e]
Érkezéskor
Magas
Jó
Magas lehet
HRRN
max((w+s)/s)
Nem
Magas
Jó
Magas lehet
Rövid folyamatoknál jó
Minimum Magas lehet
Korrekt Hosszú folyamatokat bünteti Hosszú folyamatokat bünteti Kiegyenlített
Nem Lehetséges Lehetséges Nem
I/O igényes Feedback
spec.
Időszeletnél
N.a.
N.a.
Magas lehet
folyamatokat favorizálja
38
Lehetséges
10.2.5.
FCFS (FIFO)
Működése: a legegyszerűbb algoritmus, amely beérkezésük sorrendjében futtatja a folyamatokat. Az algoritmus nem megszakítható, ha valamely folyamat blokkolódik, helyette a legrégebben a sorban található folyamat kerül kiválasztásra. Értékelés: az algoritmus előnybe részesíti a CPU igényes folyamatokat, hiszen azok sokkal ritkábban blokkolódnak, mint az I/O igényes folyamatok, az algoritmus következtében az I/O eszközök kihasználtsága meglehetősen rossz. Példa
10.2.6.
Round Robin
Az interaktív rendszerek alapalgoritmusa. Az időzítő periodikusan megszakításokat generál, a kernel minden megszakításkor másik folyamatot választ ki futásra a futásra kész folyamatok közül, így alapesetben minden folyamat egy időszeletnyi ideig futhat. Az algoritmus egyik alapvető kérdése az időszelet hosszának meghatározása. Nagyon rövid időszelet választásával a rövid folyamatok gyorsan végrehajtásra kerülnek, ugyanakkor a sok folyamatváltás komoly többletterhet ró a rendszerre. Legcélszerűbb olyan időszeletet választani, amely egy tipikus interakció végrehajtását lehetővé teszi, ez a megoldás kifejezetten jó hatással van a válaszidőre. Értékelés Használható általános célú ütemező, az I/O igényes folyamatokkal szemben igazságtalan, mivel az I/O igényes folyamat viszonylag gyorsan blokkolódik, így az időszelete egy részét elveszti, ezáltal összességében a CPU igényes folyamatok sokkal több időt kapnak, mint az I/O igényes társaik. Módosított algoritmus a fenti probléma megoldására: a várakozósor két sorból áll: az egyik „normál” várakozósoron kívül van egy sor a blokkolásból visszatérő folyamatok számára is. Amíg a második sor nem üres, a kernel ebből választ folyamatot, azonban ez a folyamat csak a blokkoláskori időszeletéből megmaradt időtartamig futhat (ezután – ha nem blokkolódik ismét – visszakerül a normál várakozósorba).
39
Példa
10.2.7.
Shortest Process Next
Az ütemező mindig azt a folyamatot választja, amelynek legrövidebb a becsült teljes kiszolgálási ideje, rövid folyamatokat favorizálja a hosszabbakkal szemben. Nem megszakítható algoritmus. Példa
10.2.8.
Shortest Remaining Time
Az SPN egy megszakítható változatának tekinthető, mindig az a folyamat lesz futásra kiválasztva, amelynek legkisebb a várható futási időszükséglete (tehát ami még hátra van). Amennyiben folyamat kerül a várakozósorba (pl. blokkolódásból visszatér), megtörténik a folyamatok felülvizsgálata, és a legrövidebb folyamat kiválasztása.
40
Példa
10.2.9.
(SPN,
SRT).
Highest Response Ratio Next
Célja a fordulási idő és az aktív idő (mikor a folyamat valóban futott) arányának minimalizálása. (Nem megszakítható módon) mindig azt a folyamatot választja ki, amely esetében az R=(w+s)/s hányados értéke a legnagyobb (w a rendszerben eltöltött összes idő, s pedig a becsült teljes kiszolgálási idő). Előnye, hogy figyelembe veszi a folyamatok korát. Példa
10.2.10.
Feedback
Az előző algoritmusok közös problémája az, hogy alkalmazásukhoz legalább becsléssel kell rendelkeznünk az adott folyamat várható futási idejéről, ez pedig sok esetben nem lehetséges. A feedback algoritmus az ütemezési döntést a folyamat eddigi „élete” alapján hozza meg. Az algoritmus megszakítható, időszelet alapú azonban 41
változtatható prioritásokat használ: minél hosszabb ideje fut a folyamat a rendszerben, annál jobban csökken a prioritása (egy minimum értékig). Értékelése Probléma, hogy az algoritmus a hosszú folyamatokat komolyan bünteti. Megoldás: különböző prioritási szintek esetén eltérő időszeleteket használ, így minél alacsonyabb a prioritás, annál hosszabb az időszelet. További probléma, hogy sok rövid folyamat könnyen kiéheztet egy hosszabb folyamatot, erre megoldás, az algoritmus egy módosított változata, ahol a várakozó folyamatok prioritása lassan növekszik. 10.2.11.
Lottó algoritmus
A klasszikus változó prioritásos ütemezők problémáit próbálja kiküszöbölni: nem lehet a folyamatoknak CPU birtoklási arányt megadni, és egy felhasználó monopolizálhatja a rendszert ha sok folyamatot indít. Minden folyamat adott számú (sors)jegyet kap, az ütemezés „véletlen” sorshúzással zajlik. A folyamatok CPU birtoklási aránya a kapott jegyek számán alapul. Ha a jegyeket a felhasználóhoz rendeljük, akkor az összes folyamata számára adunk birtoklási arányt, így nem lehet monopolizálni a rendszert. A megoldás egyik komoly hátránya az, hogy a blokkolás miatt elveszett időtöredékek valóban elvesznek, erre az algoritmus továbbfejlesztése ad megoldást, a másik pedig, hogy nehéz jó véletlen számot generálni.
Az ábrán két felhasználó 6 folyamata látható, a felhasználók egyenlő arányban kapnak cpu időt, amit a folyamataik között tetszőlegesen osztanak szét (sorsjegyek). A 16 sorsjegy közül véletlenszerűen választunk és az azt bitrokló folyamaté lesz a CPU. Az ábra a táblára került föl.
10.3.
Az ütemezők fejlődése
A fejlődés mozgatórugóit a többprocesszoros rendszerek megjelenése –és a valós idejű ütemezési igények megjelenése jelentette.
42
10.3.1.
Ütemezés többprocesszoros rendszerekben - szemcsézettség
Szemcsézettség
Leírás
Szinkronizálási időszak (utasítások)
Finom
A párhuzamosság utasítás szintű Párhuzamos feldolgozás egy folyamaton belül Konkurrens, együttműködő folyamatok multiprogramozott rendszerben Elosztott feldolgozás hálózaton keresztül összekapcsolt csomópontokon, amelyek közös környezetet alkotnak Egymástól független folyamatok
Kevesebb, mint 20
Közepes Durva Nagyon durva Független
10.4.
20-200 200-2000 2000-1M N.A.
Folyamatok és processzorok összerendelése
Az összerendelés lehet statikus (a folyamat CPU-hoz kötött) vagy dinamikus (mindig az éppen szabad CPU-t használjuk). Az SMP megoldások esetén a statikus összerendelés jelentős teljesítmény problémákat okozhat (bár sokkal egyszerűbb megvalósítani), az egyik CPU várakozósorában több folyamat várakozik, míg egy másik CPU kihasználatlanul várakozik. 10.4.1.
Kernel folyamatok és processzorok összerendelése
Kernel folyamatok CPU-hoz rendelése történhet master/slave vagy peer alapon. Master/slave esetben a kernel kulcsfunkcióit valamely CPU-hoz kapcsoljuk, ez a megoldás jelentősen leegyszerűsíti a működést, de ez a CPU könnyen szűk keresztmetszetté válhat. Teljesen dinamikus működés esetén viszont arról kell gondoskodni, hogy ha a két CPU egyszerre aktivizálja valamely kernel funkciót, akkor nehogy ütközés legyen. 10.4.2.
Egyes CPU-k multiprogramozása (statikus összerendelésnél)
Elvben lehetséges, de ha sok CPU van a rendszerben 1-1 CPU kihasználtsága nem igazán fontos. Sok esetben a szálak akkor tudnak igazán hatékonyan futni, ha egyszerre aktívak (egyéb esetben a közöttük fellépő szinkronizációs igény jelentősen visszaveti a működést). Előfordulhat, hogy több szál együttes futása fontosabb, mint minden CPU folytonos kihajtása. 10.4.3.
Folyamatok és szálak ütemezése
A tradicionális multiprocesszoros rendszerek esetén folyamat alapú ütemezés, és a folyamatokat nem kötjük hozzá processzorokhoz, jellemzően egy közös várakozósorba szervezzük őket. Mai multiprocesszoros rendszerekben az ütemezés szál alapon történik. 10.4.4.
Szálak ütemezése
Egyprocesszoros rendszerekben a szálakat a programozás megkönnyítésére használták, többprocesszoros rendszerekben a szálak már a valós párhuzamosság kihasználására is alkalmasak. Ebben az esetben azonban fontos lehet, hogy a párhuzamos szálak valóban egy időben fussanak (kommunikáció). 10.4.5.
Szálak üzemezésének módjai
Terhelés megosztás Az egyprocesszoros rendszerek esetén megismert megoldást terjesztjük ki MP rendszerekre. Jellemzői: terhelést egyenlően osztjuk szét a CPU-k között, nincs szükség központi ütemezésre, minden szabad CPU magának választ folyamatot, ehhez kell egy globális folyamat-sor. Hátrányai: a folyamat-sor szűk keresztmetszet lehet, bár ez a probléma több tíz, sőt több száz CPU esetén jelentkezik. A szálak nem biztos, hogy az előzőleg kiválasztott CPU-hoz térnek vissza, ami lokális gyorsítótárral rendelkező CPU-k esetében problématikus, több szálból álló folyamat esetén nem valószínű, hogy az összes szál egyszerre aktivizálódik, ez pedig a szál szinkronizáció során teljesítmény probléma. Hátrányai ellenére ez a legelterjedtebb ütemezési mód!
43
Csoportos ütemezés A szálak és a CPU-k között 1:1 megfelelést alakítunk ki, a folyamat futásához pontosan annyi CPU kell, amennyi szála van. Több (egy folyamathoz tartozó) szál együttes kiválasztásának előnyei: a szorosan kapcsolódó szálak szinkronizáció miatti blokkolódásának problémája jelentősen csökken, és az ütemezési terhelés többlet kisebb, hiszen egy döntés több CPU-t is érint. Ehhez az ütemezéshez szükséges valamilyen CPU foglalási algoritmus. Dedikált CPU-k A CPU-kat a folyamat élete alatt hozzárendeljük az adott folyamathoz. A csoportos ütemezésnek egy extrém formája, látszólag rendkívül CPU pazarlóan működik (hisz nincs CPU szintű multiprogramozás), bizonyos esetekben megoldás lehet a sok CPU-s rendszerekben (akár 100 feletti CPU számmal), egyetlen CPU a költségeknek töredékét képviseli és a folyamatváltások elmaradása a folyamat teljes futási idejére jótékonyan hathat. Dinamikus ütemezés Dinamikusan kezeljük a folyamatokhoz tartozó szálak számának változását. Sok esetben a folyamathoz tartozó szálak számossága folyamatosan változhat, így a statikus összerendelések nem túl hatékonyak, ezek az algoritmusok általában az operációs rendszerek és a folyamatok közötti együttműködést igénylik. Az operációs rendszer feladata a CPU-k szétosztása a folyamatok között, a többi már a folyamat szint feladata.
10.5.
Valós idejű ütemezés (általános célú OS-ek esetén)
Egyre inkább a figyelem középpontjába kerülő problémakör, ebben az esetben a végrehajtás sikere nem csak a végeredményen, hanem annak időbeliségén is múlik. Megkülönböztetünk a Hard és Soft real time feladatokat, illetve a periodikus és nem periodikus feladatokat. Hard real-time feladatok: a határidő nem teljesítése elfogadhatatlan károkat vagy végzetes hibákat okozhat. Soft real-time: a határidő inkább elvárt, mint kötelező, megsértése esetén még mindig lehet értelme a feladat végrehajtásának. Nem periodikus feladat esetén a feladat végrehajtás kezdési vagy befejezési ideje (vagy mindkettő) kötött. Periodikus esetben adott valamiféle periódusidő. Látni kell, hogy a valós idejű rendszerek szempontjából a tervezhetőség kardinális (alapvető fontsságú)! 10.5.1.
Valós Idejű OS-ek jellemzői
Megjósolhatóság: Az OS determinisztikus, ha a feladatokat fix, ismert időintervallumonként hajtja végre. A determinisztikusság meghatározza, hogy az OS mennyi időn belül tud reagálni egy megszakításra. Válaszkészség: Meghatározza, hogy az OS mennyi idő alatt hajtja végre a megszakítás kód közös részét, ez a megjósolhatósággal együttvéve vizsgálandó. Felhasználói kontroll: A rendszer finomhangolhatósága, akár egyedi folyamatok szintjén. Prioritások, VM (nem lapozható részek), diszk-kezelő algoritmusok. Megbízhatóság: Egy olyan átmeneti hiba, ami egy sima rendszernél egy reboot után megszűnik, az RT rendszernél katasztrofális lehet (mi lesz a reboot alatt?). Valamely komponens hibája (pl. CPU), ami sima rendszernél „csak” teljesítmény csökkenést okoz, itt az egész rendszert ellehetetlenítheti (válaszidők). Fail-soft működés: A rendszernek túl kell élnie a hibákat (akár csökkentett funkcionalitással). Tipikus (pl. Unix) rendszerekben ha a kernel hibát detektál megpróbálja a lehető legkisebb adatvesztéssel kezelni a problémát. Ennek tipikus módja a crash. „fail soft: Used to describe systems that are designed to terminate any nonessential processing when there are hardware or software failures. Systems in fail soft mode are still able to provide partial operational capability.„ (http://www.webopedia.com/TERM/F/fail_soft.html) 10.5.2.
Valós idejű OS tulajdonságok
• Gyors folyamat és/vagy szálváltás • Kis méret, korlátozott funkciók 44
• Gyors reagálás a megszakításokra • Multiprocessing, „komoly” IPC támogatás • Speciális fájlok gyors adatrögzítéshez (pl. szekvenciális fájlok) • Prioritás alapú, preemptiv ütemezés • Megszakítások letiltásának ideje minimális • Szolgáltatások folyamatok pontos késleltetésére • Speciális időzítési funkciók
10.6.
Valós idejű ütemezési megoldások
• Statikus, táblázat alapú megoldások – Periodikus feladatok esetén használható. Előzetes végrehajthatósági tervet készít, az ütemezés ennek alapján történik. • Statikus, prioritás alapú algoritmusok – A szituáció elemzése statikus, de az eredmények alapján az ütemezést „hagyományos” prioritás alapú ütemező végzi. • Dinamikus, terv alapú megközelítés – Új taszk indítása esetén az indítást csak akkor engedi, ha az újratervezett ütemezési terv alapján az időzítési elvárások tarthatók. • Dinamikus, „best effort” működés – Nem végzünk megvalósíthatósági analízist, a rendszer mindent megtesz, hogy a határidőket tartsa (de nincs rá garancia). Jelenleg elterjedten használt megoldás, nem periodikus megoldások esetén is működik.
10.7.
Ütemezési példa – klasszikus Unix
A tradicionális Unix ütemezője csak a felhasználói folyamatok esetén szakítja meg a futást időzítés alapján, kernel folyamatok esetén megszakítás nem lehetséges. A Unix ütemezése prioritásos, mindig a legmagasabb prioritású folyamat fut, amennyiben azonos prioritású folyamatok találhatók a várakozósorban, közöttük az ütemező RR algoritmust használva választ. Egy folyamat prioritása egy kezdeti érték mellett előéletétől függ. 10.7.1.
Folyamatok prioritása
Egy folyamat prioritása egy kezdeti érték mellett előéletétől függ, minden futási állapotban töltött időszelettel csökken, és minden várakozással töltött időszelettel növekszik. Kernel funkcióból való visszatérés után a folyamat prioritása átmenetileg a felhasználói tartomány fölé emelkedik, ezzel is biztosítva, hogy az eredmény gyors elvételével a folyamat a kernel erőforrásait a csak lehető legrövidebb ideig használja. A különböző kernel funkciókhoz más-más érték tartozik, pl. a merevlemez funkcióé magasabb, mint a terminál inputot feldolgozóé. Unix esetén a folyamatok prioritása az értékükkel fordítottan arányos, pl. a 4.3BSD esetén 50...127 között lehet (0 és 49 közötti rész a kernelnek van fenntartva).
45
10.7.2.
Prioritás számítása
Változók: • p_pri: aktuális ütemezési prioritás • p_usrpri: user módú prioritás (ez ált. azonos p_pri értékkel) • p_cpu: CPU használat mérésére szolgál • p_nice: felhasználó által megadható prioritás érték Algoritmus lépések • TMR IRQ (10 msec), aktív folyamat: p_cpu = max(p_cpu+1, 127) • schedcpu() rutint (1/sec), minden folyamat p_cpu értékét megszorozza – A szorzó értéke SVR3 esetén fix (1⁄2) – BSD esetén a rendszer aktuális terhelésétől függ - a terhelés növekedésével egyhez tart (kisebb, mint 1), így a folyamatok prioritásának növekedése nem gyorsul (nem úgy, mint konstans esetén). • Az ütemező (1/sec) újraszámolja a folyamatok prioritását p_uspri = PUSER + (p_cpu / 4) + (2 * p_nice), PUSER=50 Kevesebb ideig futó és az I/O igényes folyamatoknak kedvez (utóbbiak sokszor várakoznak, így prioritásuk növekszik).
10.8.
Ütemezési példa – Unix SVR4
Teljesen újradolgozták az ütemezőt, ez sem igazi RealTime, de már bizonyos időkorlátos műveleteket támogat. Statikus prioritású ütemezési osztály, 160 prioritási szint (egyes szinteken belül RR ütemezés). 159 ... 100: RT osztály (statikus prioritás) 99 ... 60 : Kernel 59 ... 0 : Időosztásos, változó prioritású Időosztásos tartományban az időszelet prioritás függő (P0: 100 ms ... P59: 10 ms). Megszakítási pontok kialakítása a kernelben, a kernel ettől nem lett tetszőlegesen megszakítható, de vannak benne olyan pontok, ahol biztonságban meg lehet szakítani az aktuális kernel funkciót. TS (timeshare): the default calss. Priorities (0-59) are dynamically adjusted in an attempt to allocate processor resources evently. IA (interactive): enhanced version of the TS class that applies to the in-focus windows in the GUI. Its intent is to give extra resources to processes associated with that specific window (range is 0-59). FSS (fair-share scheduler): This class is share-based rather that priority-based. Threads managed by FSS are scheduled based on their associated shares and the processor’s utilization (range is 0-59). FX (fixed-priority): The priorities for threads associated withs this class do not vary dynamically over the lifetime of the thread (range 0-59). SYS (system): The SYS class is used to schedule kernel threads. Thread in this class are "bound" threads, which means that they run until they block or complete. Priorities are in th 60-99 range. RT (real-time): Threads in the RT class are fixes-priority, with a fixed time quantum. Their priorities range 100-159.
11.
Mikor nem csak egy folyamat...
• Korai megoldások (Unix) – signal-ok – pipe és FIFO • Újabb eszközök (Unix, SysV IPC) 46
– üzenetsorok (message queue) – osztott memória – szemaforok • Az elv más rendszerekben is hasonló...
11.1.
Signalok
Aszinkron események, callback függvény jellegű megvalósítás. Legtöbbjét a kernel küldi (timer, hibák), típuson túl adatot nem közvetít, egy részük elkapható, egyesek tilthatók (de van, ami nem).
11.2.
Pipe
Bájt alapú kommunikációt valósít meg. Nincs fájlrendszer kapcsolat, csak „közeli rokon” folyamatok között működik és nem perzisztens (tartósan fennálló). int fd[2]; ... pipe(fd); if(fork() == 0) { read(fd[0], msg, 128); ... } else { write(fd[1], message, 32); ... }
11.3.
FIFO (named pipe)
Bájt alapú kommunikációt valósít meg, van fájlrendszer kapcsolat (speciális fájl), független folyamatok között is működik és perzisztens.
11.4.
Üzenetsorok
Blokk alapú kommunikáció, több-több kapcsolattal is. Header információ (int) alapján kiválasztási szabály adható. Ez is perzisztens.
47
11.5.
Osztott memória
Osztott lapok elérhetővé tétele az összes érintett folyamat címterében, hozzáférés vezérléssel.
11.6.
Szemaforok
„Klasszikus” szemafor implementáció: bináris szemaforok (0,1 érték) és számláló típusú szemaforok. Bináris szemafor kizárólagos hozzáféréshez, számláló típusú véges mennyiségű erőforrás menedzsmentjéhez alkalmas.
11.7.
Memóriakezelés
Az operációs rendszerek egyik legfontosabb funkciója. Az idők során különböző megoldások születtek, de a fő elvárások konkrét megoldástól függetlenül az áthelyezhetőség (relocation), a védelem (protection), a megosztás (sharing), a logikai szervezés (logical organization) és a fizikai szervezés (fizikai szervezés). 11.7.1.
Áthelyezhetőség
Multiprogramozott rendszerekben a szabad memória több folyamat között oszlik meg, kevés kivételtől eltekintve a programozó nem tudhatja, hogy a program pontosan hova fog betöltődni a memóriába. A 48
helyzetet tovább bonyolítja, hogy a program futás közben is swapelhető, ami ismételten a memóriabeli hely megváltozásával járhat. A program futása során többször is találkozik a címzés problémájával (vezérlés átadások, adatterülethez való hozzáférés). Az áthelyezésre megfelelő választ a processzor hardvernek és az operációs rendszernek együttesen kell biztosítania. 11.7.2.
Védelem
Folyamatotkat védeni kell a többi folyamat véletlen vagy direkt hozzáférési próbálkozásától (kód és adatterület, írásra és olvasás). A program kódok sok esetben a következő utasítás címét is dinamikusan állapítják meg, és ez az adathozzáférésekre kiemelten igaz (lásd. Tömbök, mutatók), így védelemnek is dinamikusan, minden egyes hivatkozáskor kell működnie. Komoly hardveres támogatás szükséges (szoftverrel jelentős többletmunka). Ehhez az operációs rendszer feladata a hardver (processzor) megfelelő információkkal való ellátása. 11.7.3.
Megosztás
Szükséges több folyamat számára is ellenőrzött hozzáférés (írás, olvasás, futtatás) biztosítása bizonyos memóriaterületekhez, mivel ugyanazon program több példányban való futtatása helypazarló lenne és megnőne az indítási idő, illetve szükséges a folyamatok közötti együttműködés biztosítása, az osztott memória. Megvalósítása hardver támogatást igényel. 11.7.4.
Logikai szervezés
A számítógépek memória szervezése tipikusan lineáris, egydimenziós címterű, s ugyanez igaz a másodlagos memóriára is. A programok felépítése viszont ettől általában eltér, hiszen a programokat általában nem monolitikus tömbként kezeljük, hanem modulokból felépülő rendszernek tekintjük. A modulok egy része csak olvasható (és végrehajtható), míg más részük írható és olvasható is. Ha a memóriakezelés támogatja ezt a fajta szervezést, annak több előnye is lehet: a modulok egymástól függetlenül kezelhetők, a modulok közötti hivatkozás futási időben fordul le, továbbá a memóriavédelem modul szintű megfogalmazása magától értetődő (csak olvasható, írható-olvasható, stb.) és a memóriamegosztás szintén jól kezelhető modulok szintjén (ez az a szint, amelyen a programozó is gondolkodik). 11.7.5.
Fizikai szervezés
A memória szervezése ma kétszintű. Van egy gyors és viszonylag korlátos mennyiségű elsődleges memória és lassabb, olcsóbb és sokkal nagyobb kapacitású másodlagos memória. Az elsődleges memória mérete meglehetősen korlátos (és multiprogramozott rendszerek esetén folyamatosan változó), csak a központi memória használata meglehetősen lekorlátozza a programok méretét; ezen túllépni csak programozói beavatkozással (overlay technika) lehet, amely többletmunka és igazából csak megkerüli a problémát. A legtöbb megoldás a programok számára kínált memóriát az elsődleges és a másodlagos memória valamiféle kapcsolataként hozza létre. A processzor közvetlenül továbbra is csak az elsődleges memóriához fér hozzá, így az adatok mozgatása az elsődleges és a másodlagos memóriák között az operációs rendszerek egyik legfontosabb feladata.
12. 12.1.
Memóriakezelés „VM előtti idők”
Korai rendszerekben egyetlen program, memória kezelés nem volt. Az első operációs rendszerek (monitor) megjelenésével megjelent az igény a memória védelemre (OS megvédése a programoktól). Multiprogramozott rendszereknél az OS általi, „valós” memória menedzsment megjelenése.
12.2.
Lapozás előtti megoldások
A programok számára a kért helyet egyben, összefüggő területként foglaljuk le. Az ezt lehetővé tevő algoritmusok: particionálások (fix és dinamikus), „Buddy” algoritmus, és szegmentálás.
49
12.2.1.
Fix Particionálás
A memóriát a rendszer „generálása” során fix méretű és számosságú darabra osztjuk. Egy program egy ilyen darabot „kap”. Felvetődik a kérdés, hogy „Mekkora legyen a darab?„ Ha „kicsi”, akkor a programok „nem férnek el” (overlay), ha „nagy”, akkor meg kihasználatlan, más program által nem használható helyek maradnak (belső elaprózódás). Fix particionálás alesetei Felosztás azonos méretű partíciókra, vagy eltérő méretű partíciók alkalmazása. Utóbbi, bár az előző problémákat valamelyest csökkenti, új kérdést vet föl: a partíció kiválasztásának módját. Partíció kiválasztási algoritmusok Közös várakozósor, a legkisebb szabad partíció használata. Minden programot a méretben legjobban illeszkedő várakozósorba helyezünk. Összevetés: az egyes partíciók kihasználtságára a 2. algoritmus, míg a teljes rendszer hatékonyságára az 1. algoritmus. Használat: IBM korai OS/MFT, ma már nem. 12.2.2.
Dinamikus particionálás
A fix particionálás gyengeségeinek áthidalására született. IBM OS/MVT által használt (Multiprogramming with variable number of tasks). Jellemzői: Dinamikus particionálás esetén a partíciók mérete és számossága dinamikusan változik, a program betöltésekor pontosan annyi memória allokálódik le a számára, amennyi a futásához szükséges, ezt azonban a programnak előre tudnia kell! Működés Üres memória esetén a program igénye alapján foglalunk le szabad blokkot a memóriából, majd újabb programok, újabb foglalás. De amikor a programok terminálnak, helyek szabadulnak fel és ezekből foglalunk. Előbb-utóbb a memória tele lesz olyan kis üres részekkel, ami már kevés egy programnak, ez a külső elaprózódás. Külső elaprózódás Előfordul, hogy nem tudunk újabb folyamatot indítani, bár a szabad memóriák összeges lehetővé tehetné. Megoldást a memória tömörítése jelenti, ez azonban meglehetősen erőforrás igényes tevékenység és azt igényli, hogy a kód futás közben is áthelyezhető legyen. Lefoglalandó terület kiválasztása • First-fit: első megfelelő hely • Best-fit: a lehető legjobban illeszkedő hely • Next-fit: utolsó foglalást követő „first-fit” Tapasztalatok: legjobb a legegyszerűbb „first-fit”, egy kicsit gyengébb a „next-fit” (ez gyorsan elpazarolja a felsőbb memória részeket) és a legbonyolultabb „best-fit” a legrosszabb, mert a megmarandó memória darab általában túl kicsi ahhoz, hogy abból újabb kérést ki lehessen szolgálni. 12.2.3.
Buddy algoritmus
Fix és dinamikus particionálás korlátai közé tartozik, hogy a fix particionálás során a folyamatok száma kötött, a memóriahasználat kis hatékonyságú, valamint a dinamikus particionálás esetén az algoritmusok lényegesen bonyolultabbak és a tömörítés jelentős többletráfordítást igényel. Érdekes kompromisszum a „buddy” algoritmus. A memóriablokkok mérete 2L és 2U között változhat, ahol 2L a foglalható legkisebb blokkméret, és 2U pedig a memória teljes mérete. Kezdetben a teljes memória szabad, foglaláskor pedig a rendszer egy fát épít fel, 50
felezve a memóriablokkok méretét. Ha két egy szinten lévő blokk felszabadul, azt összevonva magasabb szintre emeljük.
Buddy értékelése Általános célú algoritmusként már nem, de a mai (lapozásos) megoldásoknál sokkal egyszerűbb algoritmus. Módosított változata a mai Unix rendszerekben is megtalálható, kernel memória kezeléshez.
12.3.
Áthelyezés kérdésköre
Az eddigi algoritmusok esetén is felmerült (swap folyamat következtében, tömörítés során). Lehetséges megoldás, CPU támogatással. 12.3.1.
Áthelyezési megoldás
Címek (fajták) • logikai cím, fizikai elhelyezkedéstől független címzés (tényleges használat előtt fizikai címre kell fordítani) • relatív cím a logikai cím egy fajtája, ahol a cím egy ismert ponthoz képest relatív kerül megadásra • a programban csak ilyet lehet használni! – fizikai cím a memóriabeli „valós” (abszolút) cím. Regiszterek: „Base” regiszter, a folyamat futó állapotba kerülésekor állítjuk be, és „Bounds” regiszterek a memóriavédelemhez. A fizikai címet a CPU határozza meg, a megoldás egyben a memóriavédelmet is megvalósíthatja, hiszen a folyamat csak a „bounds” regisztereken belül férhet hozzá a memóriához.
51
12.4.
Lapozás (egyszerű)
Az alapötlet, hogy memóriát osszuk fel egyenlő méretű, de egy folyamat méreténél lényegesen kisebb (tipikusan néhány kilobyte méretű) lapokra. Tegyük meg ugyanezt a folyamatokkal is (azonos lapmérettel), ismét megjelenik a belső elaprózódás, de a lapméret miatt meglehetősen kis mértékben). Ezek után a folyamat lapjaihoz rendeljünk hozzá lapokat a fizikai memóriából. 12.4.1.
Lapok összerendelése
Folyamatos foglalás: a lapokat összefüggő módon foglaljuk a memóriában, igazából „semmi extra”. De a memória hozzáférés (a most vizsgált esetekben címtől független, ellentétban a NUMA-val). Ott foglaljunk lapot (egyesével), ahol éppen van üres, ez már komoly előnyökkel kecsegtet.
52
12.4.2.
Megoldás jellemzői
A folyamat címtere és a lapok között egyértelmű összerendelést kell biztosítani. Ez a relokációs mechanizmusba beépíthető, egy táblázat (a laptábla) segítségével minden folyamatbeli laphoz hozzárendelünk egy memória lapot.
Védelem megvalósul, hisz a folyamatok csak a saját lapjaikat láthatják, a hozzáférés-kontroll (olvasás, írás) lap szintű. A címzés teljes mértékben logikai, a folyamat összefüggő címteret lát, a cím azonban (tudva azt, hogy a lapméret mindig kettő egész számú hatványa) felbontható egy lapcímre és egy lapon belüli relatív címre. A lapcím alapján a laptáblából meghatározható a lap fizikai címe, és a cím egyszerűen generálható. A címszámításhoz CPU támogatás szükséges, a laptáblák kezelése (kitöltése) az operációs rendszer feladata. 53
12.4.3.
Szegmentálás
A programok természetes felépítését próbáljuk követni, azaz, hogy a programot különböző méretű modulokra bontjuk (ez lehet programozói vagy fordítóprogram szintű döntés), a modulokat (szegmenseket) egymástól függetlenül kezeljük a memóriában. A szegmenseken belüli címek szintén logikai címek. A címfordítás szegmenstáblán keresztül történik (összeadással), hiszen a szegmensek mérete tetszőleges. CPU támogatás szükséges hozzá! A szegmenstábla a szegmens méretét is tartalmazza, így a hozzáférés ellenőrzése is megoldott. A szegmensméret dinamikus változtatásával a futási idejű adatfoglalás és felszabadítás is kezelhető.
12.4.4.
Következmények
Egyszerű lapozás és szegmentáció esetén két fontos tényező jelenik meg, az egyik, hogy a folyamatok teljes egészében logikai címzést használnak, semmiféle közvetlen kapcsolatuk nincs a fizikai memóriával (és címekkel). A másik, hogy a folyamatokat kisebb darabokra (lapokra vagy szegmensekre) osztottak, ezek egymástól függetlenül helyezkedhetnek el a memóriában (folytonos elhelyezkedés nem szükséges, sőt előnnyel sem jár). A folyamat akkor is tud futni, ha a lapjainak (vagy szegmenseknek) csak egy része található meg a memóriában. Az utasítás lefut, ha az éppen végrehajtandó kódot és az (esetlegesen) hivatkozott adatot tartalmazó memória részek elérhetők.
12.5.
Virtuális memóriakezelés
Megjelenésekor komoly viták zajlottak a megoldás hatékonyságáról. A (nem túl jelentős) teljesítmény csökkenésért cserébe jelentős előnyökkel bír: a rendszer több folyamatot tud a központi memóriában tartani, így a CPU kihasználtsága növekedhet, a program mérete túlnőhet a fizikai memória méretén, nincs szükség alkalmazás szintű trükközésekre, és ugyanaz a program különböző memóriamennyiséggel bíró gépen is futtatható újrafordítás, illetve bármilyen alkalmazás szintű törődés nélkül (úgy, hogy a több memória jótékonyan hathat a futásra). 12.5.1.
VM működés
A folyamat indulásakor legalább annyi lapot vagy szegmenst be kell tölteni, amivel a futás megkezdődhet. Futás közben a CPU folyamatos címfordítást végez (logikai, fizikai), ha úgy találja, hogy valamely címhez nem tartozik terület a memóriában, úgy meghívja a megfelelő operációs rendszeri funkciót, amely gondoskodik a hiányzó lap pótlásáról. A programok a cache megoldásoknál is megismert tulajdonsága, hogy a kód futása során meglehetősen hosszú ideig limitált területen lévő utasításokat hajt végre (ciklusok, stb.), a feldolgozott adatok köre sem változik túl sűrűn, mindez biztosítja a VM létjogosultságát! Viszont hatékony hardver támogatás nélkülözhetetlen! 54
12.5.2.
Lapozás
Laptábla meglehetősen nagy lehet, azt a központi memóriában tároljuk (nem CPU-ban). A laptábla kezdőpontjára egy CPU regiszterre (Page table pointer) mutat. Nagy laptábla miatt, több rendszer a laptáblát magát is a virtuális memóriában tárolja (lapozható), pl. a VAX rendszereken a folyamat max. 2GB memóriát használhat, egy lap 512 byte így a laptábla maximum 2^22 darab bejegyzést tartalmazhat. Szintén elterjedt a több szintű laptábla használata, ahol az első szintű tábla mindig a fizikai memóriában van. Például 32 bites rendszeren, 4 kbyte méretű lapoknál, 4 GB címtérnél a teljes laptábla 220 bejegyzést tartalmaz, ami 4 Mbyte méretű, ez 210 lapot jelent. Ha az első szintű laptábla a fenti lapok címeit tartalmazza, akkor mérete 4 kbyte (212 – 4 byte × 210 ). Két szintű laptáblánál a címfordítás is bonyolultabb, a logikai cím három részből áll. A virtuális címtérrel arányosan növekvő laptáblák problémáját többen is próbálták megoldani, pl. UltraSPARC és az IA-64 architektúrák inverz laptábla megoldást alkalmaznak (a tábla méretét a fizikai memória határozza meg). Laptáblák miatt minden memória hivatkozáshoz legalább két hivatkozás szükséges: egy (vagy több) a címfordításhoz és egy a tényleges hozzáféréshez. A cache memóriához hasonlóan a CPU-ban a címfordítást is gyorsítják egy nagy sebességű laptábla-cache segítségével (TLB). A lapméret fontos hardvertervezési szempont, hiszen minél kisebb a lapméret, annál kisebb a belső elaprózódás, ugyanakkor növekszik a lapok száma és így a laptábla mérete. A lapok optimális méretére nincs tökéletes megoldás. Egyes processzorok változó lapméretet is támogatnak (UltraSPARC, Pentium, Itanium), azonban a mai OS-ek széleskörűen nem támogatják a változó lapméretet, bár a Solarisban van ilyen. 12.5.3.
Szegmentálás és lapozás
Egyesíti a két megoldás előnyét: a lapozás átlátszó módon biztosítja a memória hatékony használatát, míg a szegmentáció a program logikájának megjelenítését biztosítja a memóriakezelésben. A két módszer összekapcsolása esetén a szegmensek lapokból épülnek fel, így a memóriafoglalás egyszerűsödik (nem beszélve a méret változásáról). A logikai cím három részből áll: [Szegmens][Lap cím] [Offset]. A szegmenstábla az adott szegmenshez tartozó laptáblára mutat. Szegmentálás használatával a védelem biztosítása nyilvánvalóbb, mint lapozás esetén, kombinált esetben így a szegmentálási megoldás védelmét használhatjuk.
12.6.
OS szintű kérdések
OS memóriakezelés megvalósításának alapvető kérdései: • Használ-e virtuális memóriakezelést? • Lapozást, szegmentációt vagy mindkettőt használja (esetleg egyiket sem)? • Milyen algoritmusokon alapul a megoldása? Az első két kérdést nem lehet megválaszolni a hardver körülmények ismerete nélkül. Például a korai Unix rendszerek nem használtak virtuális memóriakezelést (nem volt hardver támogatás hozzá). Az elmúlt időszakban néhány primitívebb rendszer, illetve néhány speciális célrendszer kivételével az összes operációs rendszer virtuális memóriakezelést használ. A tiszta szegmentáción alapuló rendszerek ritkák, a megoldások vagy lapozáson vagy pedig lapozás és szegmentáció kombinációján alapulnak. A továbbiakban a lapozás lesz a fókuszban! A CPU által megvalósított memória kezelés távol áll a teljes megoldástól, mert minden folyamatnak saját címtere van, vannak különféle védelmi és megosztási elvárások, kezelni kell a memória foglalást, felszabadítást, és a laphibákat. A memória menedzsment megvalósítása az OS feladata, ezt a hardver, mint „végrehajtó” segíti.
12.7.
Algoritmusok – tervezési tér
Betöltési (fetch) politika, amely a lap betöltésének idejét határozza meg (első hivatkozáskor vagy előre). • Elhelyezési (placement) politika, amely a betöltendő lap fizikai memóriában történő elhelyezését befolyásolja. • Csere (replacement) politika, amely azt határozza meg, hogy szükség esetén melyik lapot cseréljük.
55
• Rezidens lapok kezelésének szabályai, melyek meghatározzák, hogy egy adott folyamathoz tartozó lapokat miként kezeljük. • Laptisztítási politika, amely a lapok felszabadítását, lemezre írását szabályozza. • Terhelés szabályozás, amely a multiprogramozás fokát adja meg. 12.7.1.
Betöltési (fetch) politika
A betöltési politika kétféle lehet, igény szerinti (demand) betöltés, amiről akkor beszélünk, ha a lapot csak akkor töltjük be, amikor arra az első hivatkozás (és ezzel együtt a laphiba) bekövetkezik. Továbbá lehet előzetes (prepaging) betöltés, mely esetén nem csak a hivatkozott lapot, de az azt követő néhány lapot is betöltjük, mert feltételezzük, hogy a program azt is használja majd. Ez a módszer a laphibák számát próbálja csökkenteni, illetve a lassú diszk miatti várakozás idejét próbálja leszorítani, annak árán, hogy esetleg feleslegesen betöltött lapokkal foglalja le a memóriát. 12.7.2.
Elhelyezési (placement) politika
A politika azt határozza meg, hogy a memória mely részére töltsük be a lapot. A legtöbb rendszer esetén a memóriakezelés módja (eltérően pl. a diszkektől) helyfüggetlen, úgyhogy e politika nem releváns. Fontos kivételt jelentenek a NUMA architektúrák, melyek esetén a memóriához való hozzáférés sebessége függ attól, hogy saját memóriáról vagy távoli memóriáról van szó.
12.7.3.
Csere (replacement) politika
Az eldobandó lap kiválasztásának szabályait adja meg. Legfontosabb alapalgoritmusok: optimális, legutoljára használt (Last recenty used), FIFO, és óra (Clock). Optimális algoritmus Az optimális algoritmus azt a lapot választja ki eldobásra, amelyre a rendszerben a lapok közül legkésőbben fogunk hivatkozni. Ez az algoritmus jövőbeli információra épít, azaz ilyen nem létezik! A valós algoritmusoknak a rendszer múltbeli viselkedése alapján kell „megjósolnia” a jövőt. Ez az algoritmus jó összehasonlítási alap. A narancs mező jelzi a laphibát, a narancs keret pedig azt, ami helyére betöltjük, az oszlopk pedig az egyes lépések.
56
Az ábra a végállapotot mutatja, az egyes lépéseket nem tettem bele, lásd eredeti diasor.
LRU, FIFO algoritmus Az LRU algoritmus a lapok használati mintájára épít, csere esetén a legrégebben használt lapot dobja el, arra gondolnak, hogy ezt a lapot fogjuk legkisebb valószínűséggel használni.Az algoritmus megvalósítása nem triviális, a lapokhoz olyan információt kell rendelni, amely alapján meghatározható a lapok utolsó használatának sorrendje. A FIFO algoritmus a lapok betöltési ideje alapján választja ki az eldobandó lapot. Ezt az információt sokkal könnyebb nyilvántartani, mint az utolsó használat idejét, így ennek az algoritmusnak a megvalósítása sokkal egyszerűbb, mint az LRU-é. LRU algoritmus (vég) ábrája A narancs mező jelzi a laphibát, a narancs keret pedig azt, ami helyére betöltjük, az oszlopk pedig az egyes lépések.
Az ábra a végállapotot mutatja, az egyes lépéseket nem tettem bele, lásd eredeti diasor.
57
FIFO algoritmus (vég) ábrája
Az ábra a végállapotot mutatja, az egyes lépéseket nem tettem bele, lásd eredeti diasor.
Clock algoritmus A cél az LRU algoritmushoz hasonlóan hatékony, de annál sokkal „olcsóbb” algoritmus létrehozása. Az óra algoritmus ilyen-olyan verziójával több operációs rendszerben is találkozhatunk. Az algoritmus működéséhez minden laphoz hozzá kell rendelni egy használati bitet. Mikor a lapot betöltjük a memóriába, a lap használati bitjét 1-es értékre állítjuk, és lapra való hivatkozás esetén a lap használati bitjét szintén 1-re kell állítani. A lapokat körkörös pufferbe szervezzük, melyhez hozzárendelünk egy mutatót (a körkörös pointer-lista az óra számlapja, a mutató pedig az ami). Lapcsere igény esetén a mutató körbejár, hogy nullás használati bittel rendelkező lapot keressen, s a lapokon átlépve (ha a használati bit egyes értékű volt), a használati bitet nullázza. Ha a mutató körbeér, akkor megáll a kezdőlapnál (ahonnan idul), és azt cseréli le. Egy lap cseréje után a mutató a kicserélt utáni lapra mutat. „Clock” algoritmus - kiindulás, majd feltöltés A kék mező értéke 0, a zöldé meg 1.
58
59
„Clock” algoritmus – 5. lap hivatkozás, nincs hely ezért nullázás
60
„Clock” algoritmus - példák más elrendezésekre
Egy konkrét példa laphibák szemléltetésére A narancs mező jelzi a laphibát, a narancs keret pedig azt, ami helyére betöltjük, az oszlopk pedig az egyes lépések.
61
Az ábra a végállapotot mutatja, az egyes lépéseket nem tettem bele, lásd eredeti diasor.
Összehasonlító táblázat Az egyes algoritmusok által okozott laphibák számának szemléltesére.
Page Buffering Problémák: az LRU és a Clock jobbak a FIFO-nál, de költségesebbek, egy nem változott lap eldobása sokkal olcsóbb, mint egy módosítotté. Megoldási próbálkozás: page buffering, jelentős megoldás VAX/VMS rendszerben. FIFO algoritmus, de nem dobja el rögtön a lapot, hanem lista végére írja, így a szabad lapok listája (nem változott), de változott lapok listája. Ha a lapra hivatkoznak, visszaszedhető a listáról. Először a szabad lapok listájáról próbál lapot osztani (tartalma ekkor veszik el igazából), és a változott lapokat „kötegelve” írja ki, így kisebb az I/O terhelés. 12.7.4.
Rezidens lapok kezelése
Virtuális memóriakezelés esetén nem szükséges a folyamathoz tartozó összes lapnak a memóriában lennie (hiszen erről szól az egész), egy adott folyamat esetén az egyidejűleg szükséges lapok számának meghatározása politikai döntéseken (is) múlik. A folyamathoz tartozó lapok számának hatásai: • Minél kevesebb lapot rendelünk egy folyamathoz, annál több marad a többi folyamatnak, azaz több folyamatot tudunk egyszerre futtatni. • A folyamatokhoz rendelt lapok számának csökkentésével a laphibák száma egyre több lesz. • A folyamatokhoz rendelt lapok számának növelése egy ideig csökkenti a laphibák számát, azonban egy határon túli növelése már nem vezet észrevehető javuláshoz. • A fenti szempontok egymásnak ellentmondanak, tökéletes (minden helyzetre egyaránt megfelelő) megoldás nincs. A rezidens lapkezelés szempontjai: 62
• Lapkészlet mérete: egy folyamathoz rendelt lapok száma a futás során állandó, vagy változhat. • Lapcsere hatásköre: lapcsere során az operációs rendszer csak a laphibát okozó folyamat lapját veheti el, vagy az összes lap közül választhat. Lokális csere
Fix lapszám
Változó lapszám
–A folyamathoz rendelt lapok száma álandó –Lapcserénél az eldobandó lap a folyamat saját lapjai közül –A folyamathoz rendelt lapok száma időről időre változhat –Lapcserénél az eldobandó lap a folyamat saját lapjai közü
Globális csere
–Nem lehetséges –Lapok száma változhat –Lapcserénél az eldobandó lap bármelyik memórialap lehet, függetlenül attól, hogy az melyik folyamathoz tartozik
Fix lapszám, lokális csere A folyamathoz rendelt lapok száma állandó, laphiba esetén az operációs rendszer az eldobandó lapot csak a folyamatok saját lapjai közül választhatja ki. Egy adott folyamathoz rendelt lapkészlet méretét a futás megkezdésekor meg kell határozni, ez történhet automatikusan (az indítandó program fajtája alapján), de kérelmezheti az indítandó program is. Ez a fajta foglalási megoldás kétélű, ugyanis ha a rendszer túl sok lapot foglal le a folyamathoz, akkor a lapok egy része kihasználatlan, ami – globálisan szemlélve – a teljes rendszer teljesítményét rontja (kevesebb folyamat futhat). Ha viszont túl kevés lapot rendelünk a folyamathoz, akkor folyamatos laphibákkal kell szembenézni, amely egyrészt rossz a folyamatnak (lassan fut), ugyanakkor a sok laphiba a rendszert is leterheli. Változó lapszám, lokális csere A lapcsere mindig a folyamat saját lapjaiból történik, azonban a rendszer periodikusan felülvizsgálja, és szükség esetén növeli vagy csökkenti a folyamathoz rendelt lapkészlet méretét. A folyamatok ebben az esetben – a fix/lokális esethez hasonlóan – meghatározott méretű készlettel indulnak, és ennek a készletnek a mérete a periodikus felülvizsgálat során változhat (a folyamat laphasználási szokásainak függvényében). Ez a megoldás meglehetősen jó teljesítményt biztosíthat, azonban sok múlik a lapkészlet méretét szabályozó algoritmuson. Változó lapszám, globális csere Ennek a politikának az implementálása a legegyszerűbb, több operációs rendszeri megvalósításban is találkozhatunk vele. Az operációs rendszer általában fenntart egy listát néhány szabad lappal, laphiba esetén erről a listáról emel le egy szabad lapot. laphiba esetén a folyamat által birtokolt lapok száma nő, probléma a lapok a folyamattól történő elvételekor lépnek föl. Amennyiben a szabad lapok száma nullára (vagy egy limit alá) csökken, valamely folyamattól lapot kell elvenni, ebben viszont bármelyik folyamat érintett lehet. E megoldás esetén jelentős teljesítmény javulást lehet elérni az ún. „page buffering” eljárás segítségével, mely esetében a folyamattól visszavett lapokat nem szabadítjuk fel azonnal. 12.7.5.
Laptisztítási politika
A laptisztítási politika a betöltési politika ellentéte, azt határozza meg, hogy lapok felszabadítása igény esetén (ha laphiba lép fel) történjék (on-demand), vagy mindig tartsunk néhány szabad lapot a rendszerben (precleaning). Gyengeségek: Előzetes laptisztás esetén olyan lapot is felszabadítunk, amire rövidesen ismét szükség lesz, azaz ezzel növeljük a laphibák számát. Igény szerinti laptisztítás esetén viszont a laphibák kezelése lesz hosszadalmas (hiszen ilyenkor esetleg ki is kell írni az eldobandó lap tartalmát a másodlagos tárolóra). A „page buffering” algoritmus ezen a problémán is segít, hiszen ebben az esetben egy, a közelmúltban felszabadított lapra történő hivatkozás esetén a lap könnyen visszanyerhető.
63
12.7.6.
Terhelés szabályozás
Memóriában található folyamatok számának korlátok közé szorítása: túl kevés folyamat esetén a rendszer kihasználtsága lesz alacsony, túl sok folyamat esetén pedig a laphibák száma emelkedik túlzottan magasra. Rendszer kihasználtsága a folyamatok számának tükrében: a folyamatok számának növelésével eleinte javul a rendszer kihasználtsága, egy maximum érték után viszont a görbe csökkenni kezd. A folyamatszám további növelésének következménye a „trashing” jelenség, mikor a CPU idejét folyamatosan a laphibák kezelését szolgáló kód futtatásával tölti. Ha a terhelés meghaladja az optimális értéket, az operációs rendszernek néhány folyamat futását fel kell függesztenie (suspension), és a teljes folyamatot (minden lap) a másodlagos tárolóra másolnia. Felfüggesztendő folyamat(ok) kiválasztása A felfüggesztendő folyamat(ok) kiválasztása különböző szabályok alapján történhet: • legalacsonyabb prioritású folyamatok kiválasztása, • laphibát okozó folyamatok, mert valószínű, hogy ezek újabb laphibákat fognak előidézni, • a legutoljára indított folyamat, mert valószínűleg ez még nem töltötte be a futásához szükséges összes lapot, • legkevesebb lapot birtokoló folyamat, mert ennek mentése és visszatöltése a „legolcsóbb”, • legtöbb lapot birtokló folyamat, mert ennek felszabadítása eredményezi a legnagyobb javulást a rendszer állapotában. Minden mindennel összefügg Az operációs rendszerek esetén nincs „elsőbbség” a modulok között, azok gyakran összefonódnak egymással. Virtuális memóriakezeléshez a diszken foglalunk helyet a lapoknak, ugyanakkor a diszkműveletek gyorsításához a központi memóriában foglalunk le helyet cache célra, valamint a multiprocesszoros rendszerekben a folyamatok tetszőleges CPU-n való futtatása a kihasználtságot javítja, de a CPU-k TLB-ének hatékonyságát rontja, stb...
12.8.
Windows VM kezelés
A Windows kezdettől fogva virtuális memóriakezelésen alapuló rendszer, lapmérete változó lehet, de platform szinten fix. 32 bites verzió esetén a 4 GB-s címtér felét a felhasználói folyamatok használhatták, felét pedig a rendszer. Voltak próbálkozások a 4 GB felosztás átalakítására (bizonyos verziókban), de a 64 bites rendszerek megjelenése miatt effajta trükközésre nincs szükséges. A Windows rezidens lapkezelése változó lapszámú, de lokális cserével működik.
12.9.
Unix VM kezelés
A Unix rendszerek memóriakezelése az OS története során sokat változott. A kezdeti változó particionálást alkalmazó megoldásokat felváltották a virtuális memórián alapuló technikák. Kezdetben (és még nagyon sokáig) a kernel által használt memória statikusan volt lefoglalva a modern Unix verziók esetében már a kernel is használ memória menedzsment megoldást, igaz nem a lapozást. A folyamatok és a buffer cache kezelése lapozáson alapuló virtuális memóriakezeléssel történik, a kernel folyamatosan fenntart valamennyi szabad lapot, amiből kielégíti a folyamatok lapfoglalási igényeit. Ha a szabad lapok száma egy meghatározott szint alá csökken, a kernel elkezd lapokat visszavenni a folyamatoktól. 12.9.1.
Unix lapcsere algoritmus
A lapcsere algoritmus a „clock” algoritmus finomított változata, két mutatóval. Az első mutató körbeforogva nullázza a használati biteket, de a lapok kiválasztását a második mutató végzi, így ha közben a lapot használják, úgy annak használati bitje ismét egy lesz. Az algoritmust két paraméter jellemzi: (i) a mutatók forgási sebessége, és (ii) a fáziseltolás a két mutató között.
64
12.9.2.
Memória menedzsment paraméterek
A paraméterek kernel konfigurációjától, a fizikai memória mennyiségétől függenek. Név Leírás lostrfree desfree minfree slowscan fastscan scan rate 12.9.3.
Amennyiben a rendszerben a szabad lapok száma ezen érték alá csökken, a rendszer megkezdi lapok felszabadítását A rendszerben található lapok elvárt értéke A szabad memória legalacsonyabb, még elfogadható szintje. Ha a szabad lapok száma ezen érték alá csökken a memória felszabadítás drasztikusabb lesz Másodpercenként átvizsgálandó lapok számának minimuma (scan rate) Másodpercenként átvizsgálandó lapok számának maximuma (scan rate) Rendszer dinamikusan számolja, slowscan < sr < fastscan
Swapping
Soft swapping: ha a rendszerben a szabad lapok elmúlt 30 másodperces átlaga a desfree érték alatt volt, a kernel inaktív folyamatokat keres és azokat teljesen eltávolítja a memóriából (swap). Hard swapping: több feltételnek is teljesülnie kell, amelyek azt jelzik, hogy a rendszer komoly memóriagondokkal küzd (szabad lapok száma, lapcsere aktivitás foka, stb.). Ebben az esetben a kernel nem használt modulokat és aktív folyamatokat is swap-elhet. A swapping rendkívül erőforrás igényes, megjelenése kerülendő (memória bővítés)! 12.9.4.
Kernel memória menedzsment
A kernel memóriaigényét a buddy algoritmuson alapuló megoldás elégíti ki, mely „lazy buddy” névre hallgat. A buddy algoritmus működése során a blokkok szétosztása és összevonása erőforrás igényes, a kernel esetében (a használat jellege miatt) gyakori hogy egy éppen összevont blokkot kell szétosztani. A lazy buddy algoritmus ezért nem egyesíti rögtön a blokkokat, hanem a lehető legkésőbbig próbálja kitolni ezt a feladatot, akkor viszont a lehető legtöbb blokkot egyszerre egyesíti.
13.
I/O kezelés
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, ezért további jellemzők vizsgálata szükséges!
13.1.
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)
65
13.1.1.
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, és a sávszélesség nem köthető a kapcsolat fajtájához! Billentyűzet kevesebb, mint 100 bit/sec Ethernet: 109 bit/sec. Eszköz Átviteli sebesség (10n bit/sec) Giga ethernet Grafikus megjelenítő HDD 13.1.2.
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. 13.1.3.
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. 13.2.
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. programkód megadása és a folyamat indítása (I/O csatorna)
A központi CPU feladata a
– Az I/O processzor nem a központi memóriát használja, hanem dedikált memóriával rendelkezik
13.3.
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ú, ezért 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 mind OS szintjén (belső struktúrák), mind a folyamatok felé nyújtott interfészen (read, write, open, close, lock, unlock) keresztül. A megoldást a hierarchikus struktúrák alkalmazása jelenti. 66
13.4.
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 feladata az általános I/O funkciók szolgáltatása a folyamatok felé, az eszköz I/O feladata az I/O kérések „lefordítása” eszköz specifikus parancs-szekvenciákra, és az ütemezés, vezérlés feladata pedig az I/O műveletek sorba állítása, ütemezés (pl. IRQ-k kezelése).
13.5.
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ó), és a beviteli műveletek esetén csak az „igény szerinti” (on- demand) működés képzelhető el. Pufferelésnél 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 és cirkuláris pufferek. 13.5.1.
Egyszeres puffer
A műveletek egy kernel pufferbe/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 ekkor a memória menedzsment elbonyolódik. 13.5.2.
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, ez gyorsabb, mint az egyszeres, de bonyolultabb is. 13.5.3.
Cirkuláris pufferek
A dupla pufferelés továbbgondolása, a kernel n puffert rendel egy folyamathoz, ez bizonyos esetekben tovább gyorsít. A megoldás a „termelők-fogyasztók” modellel írható le.
67
„The consumer producer problem (also known as the bounded-buffer problem) is a classical example of a multi-process synchronization problem. The problem describes two processes, the producer and the consumer, who share a common, fixed-size buffer used as a queue. The producer’s job is to generate a piece of data, put it into the buffer and start again. At the same time, the consumer is consuming the data (i.e., removing it from the buffer) one piece at a time. The problem is to make sure that the producer won’t try to add data into the buffer if it’s full and that the consumer won’t try to remove data from an empty buffer.„ (Wikipédia, http://en.wikipedia.org/wiki/Producer-consumer_problem) További magyar nyelvű leírás a http://aries.ektf.hu/∼hz/pdf-tamop/pdf-03/html/ch05.html
14.
problémáről
itt:
Diszk I/O
Probléma, hogy a 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), a 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.
14.1.
Diszkek teljesítményének elemei
• 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 idejével és az I/O csatornára való várakozás ideje (ha az osztott). 14.1.1.
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), ahol b az átviendő bájtok, r a forgási sebesség, és N a track mérete bájtban. 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. 1. megoldás: összefüggő elhelyezkedés – 5 track 68
(a) 1. track: seek + forgás + 500 rekord olvasása = 10 ms (b) 2...5. track: 4x(forgás + olvasás) /no seek/ = 24 ms (c) Összesen: 34 ms 2. megoldás: véletlenszerű elhelyezkedés (a) 2500 x (átlagos seek + átl. Forgás + olvasás) (b) 2500 x (4m+2m+16u) = 14.6s! (c) Összesen: 14.6 s Tanulságok 34 msec vs. 14.6 sec (nagyságrendi eltérés) 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!
14.2.
SSD
Új, ígéretes, drága, saját problémákkal. A 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ő), és „Wear-out”, azaz egy adott terület csak véges számú alkalommal írható (kb. 1.000.000 írás) jellemzi.
Forrás: http://www.usenix.org/event/usenix08/tech/full_papers/agrawal/agrawal_html/ SSD esetén a tulajdonképpeni olvasás lassabb, de a késleltetés nagyon kicsi. Írás esetén a törlést is figyelembe kell venni, ami viszont rendkívüli mértékben visszafog! Mit jelent ez? SSD hatékony használata új megoldásokat kíván a „hagyományos” diszkekhez képest: fájlrendszerek, speciális Flash driver-ek.
flash specifikus
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).
14.3.
Diszk ütemezés
A következőkben tárgyaltak alapvetően a hagyományos merevlemezekre igazak! Diszk kérések hatékony kiszolgálására multiprogramozott rendszerekben tökéletes megoldás nincs. Tárgyalt algoritmusok: FIFO, prioritásos, LIFO, SSTF, scan (és változatai). 69
14.3.1.
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 viszont a hatékonysága drasztikusan romlik. Prioritásos: mindig a legnagyobb prioritású kérést, emiatt 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 itt is 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 itt is lehetséges. 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. A középső részeket favorizálja, és 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.
14.4.
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), vagy mindkét irányban (write back). Memória felhasználás módja: fix (előre meghatározott), vagy 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, vagy sztott memória használata. Blokkcsere algoritmusa: LRU (least recently used), LFU (least frequently used), vagy frequency-based.
14.5.
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, 70
• 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 a kapacitás növelését, a teljesítmény növelését és a megbízhatóság növelése. 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, és 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, de a különböző gyártók további szinteket is definiálnak, valamint 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. 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, és az adatátvitel végrehajtásának teljesítménye (átviteli sebesség). A terhelés jellege lehet kevés számú, kis párhuzamosságú, de nagy mennyiségű adatot mozgató terhelése (pl. kötegelt feldolgozás), vagy nagy számú, magas párhuzamosságú, de kicsi adatmennyiséget érintő terhelés (tranzakciós rendszerek). Kapcsolat a fentiek között a nagy mennyiségű adatot mozgató terhelésnél az adatátvitel teljesítménye domináns, míg nagy tranzakciószámnál a késleltetések sokkal fontosabbak. Olvasás és írás műveletek különbsége redundáns tároláskor abban jelentkezik, hogy olvasáskor csak annyi adatot kell beolvasni, ami elegendő a kért adatblokk biztosításához, míf íráskor az adatblokkhoz tartozó összes részt aktualizálni kell. Ezért vizsgáljuk a tárolás módjár és a viselkedést íráskor illetve olvasáskor. A példákban a diszkek száma N, egy diszk átviteli sebessége pedig T. 14.5.1.
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! 71
• Í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! 14.5.2.
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. 14.5.3.
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).
72
14.5.4.
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.
14.5.5.
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ó. 73
∗ 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. – Hiba esetén: 1 írási tranzakció szolgálható ki. ∗ Tranzakciónkénti átviteli sebesség << T. 14.5.6.
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. 14.5.7.
Egyéb források RAID szintekről
RAID0,1,3,5,10: http://www.prepressure.com/library/technology/raid(angol) RAID0,1,5,10: http://www.thegeekstuff.com/2010/08/raid-levels-tutorial/ (angol) RAID0,1,2,3,4,5,6,01,10: http://hu.wikipedia.org/wiki/RAID (magyar) RAID0,1,3,5,01,10: http://www.sohoconsult.ch/raid/raid.html (angol)
15.
Fájlok, fájlrendszerek
Felhasználói szempontból az operációs rendszer (egyik) legfontosabb része, mert ezzel közvetlen „találkozik”, a fájlok tárolása, hozzáférés alapvető, és a teljesítmény szempontjából kritikus. Alapvető elvárások Hosszú távú tárolás: A fájlokat másodlagos tárolón (tipikusan merevlemezen) tároljuk, ahol 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ő és 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, valamint 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 Az általános modellban létrehozás, törlés, megnyitás, lezárás, olvasás és írás van, de az egyes konkrét implementációk további műveleteket is definiálhatnak. 74
Fájl struktúrák A struktúra-elemei: • 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.
15.1.
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.
15.2.
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)
75
15.3.
Fájlrendszer architektúra
15.3.1.
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ú) 76
15.3.2.
Unix I/O (klasszikus)
Hozzáférés fájl-interfészen keresztül, kétféle eszköz (blokkos, karakteres) és az eredeti buffer cache fix.
15.4.
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).
15.5.
Unix I/O
Klasszikus megvalósításban statikus táblázatok, ahol új hardver illesztéséhez új kernel kell (a meghajtó programok statikusan betöltve), ezért sok esetben előre „belepakoltak” minden drivert a kernelbe. Modern megvalósításban dinamikus kernelek, ahol a különféle meghajtó programok futási időben is betölthetők (igény szerint), viszont függőségeket kezelni kell. Lényegesen rugalmasabb és erőforrás takarékosabb lesz a működés, de a kernel sokkal bonyolultabbá válik.
15.6.
A közelmúlt (90-es évek) Unix fájlrendszerei
Fájlrendszer interfész és keretrendszer változásai, több fájlrendszer egyidejű támogatása. Többféle fájlrendszer megjelenése eltérő jellemzőkkel: szolgáltatások (pl. hosszú fájlnevek), méret (fájlrendszer, fájlok), teljesítmény, 77
megbízhatóság, speciális funkciók (pl. tmp terület). 15.6.1.
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ő, bár ú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 a több fájlrendszer támogatása, ennek megoldása a vnode/vfs interfész. 15.6.2.
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), és 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. A 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, a fájlok (távoli) megosztásának támogatása, és a saját fájlrendszerek típusok létrehozásának lehetősége. Vnode/vfs koncepció Objektum szemléletű megközelítés: a vnode a fájlok absztrakciója, a vfs pedig fájlrendszeré a Unix kernelben. Az absztrakt alaposztályok, minden tényleges fájlrendszer-implementáció ősei. Az osztályok adatelemei és metódusai virtualizáltak, és a funkciók két szintre oszthatók. Egyik az alacsony szintű funkciók (pl. open, read), ezeket egyes fájlrendszer-implementációk implementálnak, a másik a 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. „Reentráns: Olyan kód, amelybe azonos thread egyszerre többször is (pl. rekurzívan hívja önmagát egy függvény), vagy több thread egyszerre beléphet anélkül, hogy a változók/erőforrások kezelése hibásan történne. Éppen ezért nem használhat statikus változókat (leggyakrabban emiatt nem reentráns egy függvény), legalábbis megfelelő lock-olás vagy egyéb adminisztráció nélkül. A hagyományos Unix libc függvények közül sok nem reentráns (pl. gethostbyname, localtime, strerror, stb), ezek reentráns változata általában a ’_r’ postfixet kapja (már ahol implementálják). A reentráns változatnál gyakran az API-n is módosítani kell.„ (hupwiki, http://wiki.hup.hu/index.php/Reentr%C3%A1ns)
78
15.6.3.
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 a MS-DOS FAT (pl. Solaris esetén) és a CD (pl. ISO 9660), DVD támogatás. 15.6.4.
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ő, ahol a blokkok mérete 512 szorzata 2 egész számú hatványával és 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: (i) boot terület, (ii) szuper blokk, (iii) i-node lista, és (iv) 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, ennek felépítése: 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ő, a root könyvtár i-node értéke: 2. Az index node fájl adatait tárolja (kivétel név). Egy 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), ez 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, és 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. Szabad i-node blokkok nyilvántartására csak részleges lista van a szuperblokkban, ha elfogy, a rendszer szabad blokkokat keres a diszken. Szabad diszk blokkok nyilvántartása. Szabad diszk blokkok nyilvántartása: az összes szabad blokkot nyilván kell tartani, teljes lista szuperblokk-ban tartása nem lehetséges, továbbá 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álva. Olvasási művelet (példa): blokk diszk-beli címének meghatározása, ezután lap foglalás kernelben, megadva az előbb kiszámolt cím, majd 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, és ha nem teljes blokkot ír, akkor visszaíráskor szükség van a diszken található adatokra is. 79
A fájlrendszer értékelése Egyszerűsége kiemelkedő, de problémák több területen is jelentkeznek, ilyen a megbízhatóság, a teljesítmény és a 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, ráadásul az i-node foglalás véletlenszerű, nem ügyel kapcsolatokra (pl. egy könyvtár fájljai). Ugyan 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, ezzel jobb teljesítmény, de sok pazarlás), végül a 14 karakteres fájlnév komoly funkcionális korlát. 15.6.5.
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, és a szuperblokk adatainak egy része is a cilinder-csoportokba vándorol. Biztonság növelés érdekében pedig a szuperblokk több példányban „elszórtan” vannak tárolva. 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), de az új alkönyvtárat eltérő csoportba helyezi. A fájl blokkokat egy csoportba helyezi az i-node blokkal, a pedig 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) történik. 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ámogatása, 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ó. A 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 viszont 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ő, ezek 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. 15.6.6.
Speciális fájlrendszerek
tmpfs Átmeneti adattárolás (tmp terület), sok alkalmazás intenzíven használ átmeneti fájlokat, ilyenkor 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.
80
procfs Célja a 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 történik. 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). 15.6.7.
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...
15.7.
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). A megvalósítás jelentős számú tervezési kérdést vet föl. 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 vagy metaadat változásokat • 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)
16.
Egyéb témakörök
Amik a diákban nincsenek, de az anyag része.
16.1.
Adatmentés módszerei (backup)
Egy az egyben kimásolva innen: http://www.biztonsagosinternet.hu/tippek/az-adatmentes-modszerei Szerintem remekül összefoglalja a lényeget. „Teljes adatmentés A teljes adatmentésnél az összes mentendő fájlt egy bizonyos időpontban egy kiegészítő adathordozóra mentjük. Előny: minden adatbázis kompletten kéznél van. Az adatbázisok visszaállításánál nem kell hosszan keresgélnie. Hátrány: attól függően, hogy mennyi adatot tárol, sok időt vehet igénybe a teljes adatmentés. És sok helyet foglal el a tárolóeszközön. Inkrementális adatmentés Ehhez először teljes adatmentést kell végeznie. Azután már csak azokat az adatbázisokat menteni, amelyek a legutolsó teljes mentés ill. a legutolsó inkrementális mentés óta megváltoztak. Előny: tárolóhelyet takarít meg és kevesebb időre van szüksége. Hátrány: ami időt a mentésnél megtakarít, azt az adatok visszaállításánál kell majd ráfordítania. Szükség esetén ugyanis először a legutolsó teljes mentést kell rávinnie a rendszerre. Utána a tejes mentés utáni inkrementális mentést kell felrakni a rendszerre. Ha csak egyetlen adatot szeretne visszaállítani, nagyobb a ráfordítás, mint a teljes adatmentés esetében. Ugyanis az összes inkrementális mentést, sőt az utolsó teljes mentés anyagát is át kell néznie ahhoz, hogy a keresett adatbázis megfelelő verzióját megtalálja. 81
Differenciált adatmentés Ehhez is teljes mentést kell végeznie először. Utána minden differenciált mentésnél csak azokat az adatokat menti, amelyek az utolsó teljes mentés óta változtak. Előny: az adatok visszaállítása szükség esetén egyszerűbb és gyorsabb. Csak az utolsó teljes mentés, és az aktuális differenciált mentés kell hogy kéznél legyen. Hátrány: az inkrementális mentéshez viszonyítva több időre van szüksége és több helyre az adathordozón eszközön.„
16.2.
FUSE
• http://en.wikipedia.org/wiki/Filesystem_in_Userspace
16.3.
ZFS
• http://en.wikipedia.org/wiki/ZFS • http://hub.opensolaris.org/bin/view/Community+Group+zfs/whatis 16.3.1.
Copy-on-write
http://en.wikipedia.org/wiki/Copy-on-write
82
