6.6 Persistenter virtueller Speicher

Transkript

1 6.6 Persistenter virtueller Speicher Idee: alle Segmente sind persistent Datei -Begriff überflüssig! Aber: Segment hat erweiterten Deskriptor. bs-6.6 1

2 Segment überdauert Tod des erzeugenden Prozesses, Systemabschaltung, Systemabsturz, solange es über eine Berechtigung oder einen Namen erreichbar ist (sonst Speicherfreigabe!). Probleme: Lösung: Anzahl der Segmente! Inter-Segment-Adressierung! - entweder objektbasierte Adressräume ( 6.6.1) - oder unendliche Adressräume ( 6.6.2) bs-6.6 2

3 6.6.1 Objektbasierte Adressräume (z.b. in DAS (TU Berlin ), Clouds (Georgia Tech ), Birlix (GMD Birlinghoven ), u.a.) minimale Segmentstruktur, z.b. lediglich Code, Daten, Keller Modul oder Objekt oder Code, Moduldaten, Objektdaten, Keller Objekt bs-6.6 3

4 Objektidentifizierung über Berechtigung Objektaufruf/rücksprung bewirkt Wechsel des Adressraums unter Beibehaltung des Kellers, ist Mikrokern-Systemaufruf in prozedurorientierter Architektur (kein technischer Unterschied zwischen Benutzer- und Systemobjekten) bs-6.6 4

5 Berechtigungen Deskriptoren für Objekte für Datensegmente für Codesegmente x c Objekt x vom Typ c bs-6.6 5

6 Codesegment beginnt mit Sprungleiste: 8: 125: JUMP 0008 JUMP 0125 JUMP 4711 JUMP... JUMP... JUMP... JUMP... JUMP... bs-6.6 6

7 Objektaufruf: CALL(objCap, opno, args) enthält keine Code/Daten-Adressen, wohl aber Berechtigungen! Objektrücksprung: RETURN (vgl ) bs-6.6 7

8 Typisches Sharing-Szenario: Prozess P Prozess Q P-Keller Q-Keller ObjektX ObjektY ObjektZ CodeC Code Sharing CodeD Object Sharing bs-6.6 8

9 Einfache sequentielle Daten als Objekte? Ineffizient! Daher Aufweichung der starren Objektstruktur: zusätzlich freie Datensegmente (greifbar über Berechtigungen und map/unmap-operationen) Parameterübergabe bei CALL/RETURN kann Berechtigungen für Objekte und freie Segmente beinhalten bs-6.6 9

10 6.6.2 Unendliche Adressräume Wünschenswert: freie Inter-Segment-Adressierung ermöglichen Adressraumwechsel vermeiden Segmentkollisionen im Adressraum vermeiden Realisierung: Jedem realen Segment ist ein eigenes virtuelles Segment für alle Prozesse identisch! zugeordnet. bs

11 Folgerung: unendlicher Adressraum wäre schön hat Platz für beliebig viele Segmente, erlaubt Verzicht auf Wiederverwendung virtueller Segmente (!), die mit technischen und Sicherheitsproblemen verbunden ist.? Was leisten 64-Bit-Adressen?? Braucht man 128-Bit-Adressen? bs

12 64-Bit-Adressen: adressierbar sind * Bytes, Segmenterzeugung mit Rate 1000/sec à 10 6 Bytes verbraucht pro Sekunde 10 9 Adressen, Pro Tag (86400 sec) werden damit weniger als Adressen verbraucht, 16*10 18 / = 16*10 4 Adressen reichen für mindestens Tage. (Produkte seit 1992: DEC, AMD, Sun, Intel, IBM,...)! Für netzweite Adressräume verteilter Systeme wurden sogar schon 128-Bit-Adressen realisiert (MONADS, Univ. of Newcastle, Australien, ) bs

13 Typische Charakteristika unendlicher Adressräume: Berechtigungen für Segmente, map/unmap Seitentabellen auslagerbar (Seitentabelle entspricht file map im Dateideskriptor!) integrierte Speicherbereinigung (für realen Speicher!) bs

14 Beispiel MONADS Hardware: 128-Bit-Adressraum mit Paging Segmente* nicht an Seitengrenzen gebunden Capability-Register für capability-basierte Adressierung: base length rights R,W,X * haben festes Format (control, capabilities, regular data) bs

15 MONADS-Betriebssystem (Newcastle, Bremen, Ulm [Keedy et al.]) realisiert damit objektbasierten, persistenten Adressraum: Module Capability: module handle rights meta-rights kein map wegen capability-basierter Adressierung: jeder Prozess hat gleichen Adressraum mit allen existierenden Segmenten kann aber nur diejenigen Segmente ansprechen, für die er Berechtigungen hat. ( Berechtigung in Register laden map ) bs

16 6.6.3 Stabiler Speicher (stable storage) = durch Systemsoftware realisierter virtual storage mit der Eigenschaft, sogar Hardware- und Systemzusammenbrüche unbeschadet zu überstehen im Gegensatz zum flüchtigen Speicher (volatile storage), dem Arbeitsspeicher; wird (natürlich) mit Hilfe des externen Speichers realisiert. Voraussetzung: keine Plattenschäden (andernfalls Platten duplizieren ( spiegeln )) bs

17 Grundprinzipien: regelmäßige Sicherungs-Operation hinterlässt Platten in konsistentem Zustand (s.u.). Nach Sicherung geänderte Seiten werden beim Verdrängen auf neu bereitgestellte Platten-Sektoren hinauskopiert ( shadow pages ); Seitentabelle wird entsprechend geändert und selbst entsprechend gesichert (da selbst im virtuellen Speicher!). Wurzelseite der Seitentabelle und ihre shadow page werden im Arbeitsspeicher gehalten. bs

18 Sicherungs-Operation: Die Wurzelseite der Seitentabelle wird durch ihre shadow page ersetzt im Arbeitsspeicher und auf der Platte. bs

19 Sicherungs-Operation: Die Wurzelseite der Seitentabelle wird durch ihre shadow page ersetzt im Arbeitsspeicher und auf der Platte. shadow pages bs

20 Aktuell ist die gesicherte Version unter der Voraussetzung, dass eine geänderte Seite möglichst bald verdrängt wird. Korrekt ist dieses Verfahren unter der Voraussetzung, dass das Schreiben eines Blocks auf die Platte ein hardwaremäßig atomarer Vorgang ist. bs

21 Aktuell ist die gesicherte Version unter der Voraussetzung, dass eine geänderte Seite möglichst bald verdrängt wird. Korrekt ist dieses Verfahren unter der Voraussetzung, dass das Schreiben eines Blocks auf die Platte ein hardwaremäßig atomarer Vorgang ist. Falls nicht: 2 vergangene Versionen auf Platte halten von denen die ältere garantiert konsistent ist: Versionierte Wurzelseiten: n-1 n-1 n n-1 bedeutet: wurde nicht vollständig geschrieben! bs