Ein- und Ausgabe I/O WS 12/13 IAIK 1
I/O Überwachung der I/O eine der Hauptaufgaben Kommandos Interrupts Fehlerbehandlung Einfache, einheitliche Schnittstelle zur HW für Applikationen Geräteunabhängigkeit IAIK 2
Hardware Aus dem Gesichtspunkt der Programmierung Hängt mit Aufbau und Arbeitsweise der Hardware zusammen IAIK 3
Kategorisierung Blockorientierte Geräte (block devices) Speichert Informationen in Blöcken fixer Größe Können unabhängig voneinander gelesen/geschrieben werden Beispiel: Festplatten IAIK 4
Kategorisierung Zeichenorientierte Geräte (character devices) Erzeugt und akzeptiert Zeichenströme (character streams) ohne Rücksicht auf Blockstruktur Nicht adressierbar, keine Suchfunktion Beispiel: Drucker, Keyboard, Mäuse, Netzwerk IAIK 5
Kategorisierung Sonstige Devices Uhren Bildschirme Allgemeines Modell, erlaubt es Teile des BS geräteunabhängig zu gestalten IAIK 6
Controller I/O-Geräte haben mechanische Komponente (Gerät) und elektronische Komponente (Controller) Controller steuert Gerät konvertiert Datenströme IAIK 7
Beispiel: Festplatte Festplatte liefert Vorspann, 4096 bit Sektordaten, Prüfsumme Controller konvertiert Daten in Byte-Blöcke, führt eventuell Fehlerkorrektur durch und kopiert Daten in Hauptspeicher IAIK 8
Kommunikation mit Controller über Register Beschreiben der Register: Befehle erteilen Auslesen: Statusabfrage Datenpuffer IAIK 9
Kommunikation I/O-Befehle und I/O-Ports IN REG, PORT OUT PORT, REG Getrennte I/O- und Datenadressräume IN R1,4 MOV R1,4 IAIK 10
Kommunikation Einblenden der Kontrollregister in den Hauptspeicher wie Hauptspeicher angesprochen Memory-Mapped I/O Adressen meist oben im Speicher Kombinationen möglich (Pentium) IAIK 11
Vorteile keine speziellen I/O-Befehle, daher in Hochsprache programmierbar Kontrolle über Einbindung virtueller Seiten in Adressraum des Prozesses realisierbar Gerätetreiber unterschiedliche Adressräume Weniger Befehle für zb Tests, da spezielle Speicherbefehle verwendbar IAIK 12
Nachteile Cachen muss verhindert werden komplexere Hardware Alle Geräte und Speichermodule müssen alle Speicherzugriffe prüfen was aber, wenn mehrere Busse? schnellere Busse für Memory Standard IAIK 13
mehrere Busse nicht alle Speicherzugriffe auf allen Bussen sichtbar Lösung: Filtern von Adressen z.b. Northbridge/Southbridge (Intel) IAIK 14
DMA Daten von Controller zeichenweise holen aufwändig DMA: Controller transferiert Daten selbständig ins Memory DMA-Controller (pro Gerät oder zentraler Baustein) hat immer Zugriff auf Systembus IAIK 15
DMA IAIK 16
Wortweise/Blockweise DMA-Controller bekommt ein Wort vom device benötigt Bus Prozessor muss auf Bus warten cycle-stealing Bus wird belegt, Übertragung durchgeführt, Bus freigegeben burst-mode effizienter, aber Bus länger blockiert IAIK 17
fly-by Modus Daten vom Gerät an den Controller (Puffer) von Controller direkt in Hauptspeicher können auch an DMA-Controller geschickt und von diesem an Gerät weitergeleitet werden IAIK 18
virtuelle Adressen DMA-Controller verwendet physische Adressen Betriebssystem muss virtuelle Adressen umrechnen IAIK 19
warum Puffer im Controller? Prüfsummen Geräte liefern Daten in konstanter Geschwindigkeit Bus könnte aber nicht frei sein! IAIK 20
I/O-Design-Kriterien IAIK 21
Ziele von I/O-Software Geräteunabhängigkeit Programme sollten mit Daten von Festplatte, Band, CD, Diskette etc und das ohne Änderung sort < input > output egal wo input und output herkommen IAIK 22
Ziele von I/O-Software Einheitliches Namensschema unabhängig vom Gerät Unix: alles unter / Fehlerbehandlung möglichst Controller oder das Betriebssystem transiente Fehler transparent IAIK 23
I/O-Software synchron/asynchron I/O ist asynchron Software will aber bei read warten bis was da ist Pufferung Daten können nicht immer am Speicherziel abgelegt werden gemeinsam/exklusiv benutzbare Geräte IAIK 24
I/O-Durchführung Drei Arten Programmiert mit Interrupts mit DMA IAIK 25
Programmierte I/O Prozess will Zeichen am Drucker ausgeben Systemcall Drucker belegt return mit Fehler Prozess blockiert bis Drucker frei (Spooling) IAIK 26
Programmierte I/O IAIK 27
Programmierte I/O Betriebssystem kopiert Zeichen in Kernel-Puffer leichter adressierbar Warten bis Drucker verfügbar erstes Zeichen in Datenregister des Druckers Drucker bereit für zweites Zeichen? IAIK 28
Programmierte I/O IAIK 29
Programmierte I/O Nachteil: Prozessor belegt bis Drucken fertig ok, wenn Wartezeit zwischen den einzelnen Zeichen sehr klein Prozessor nichts anderes zu tun (z.b. embedded systems) in komplexeren Systemen nicht ok! IAIK 30
Interruptgesteuerte I/O Wartezeit zwischen den Zeichen lang programmierte I/O nicht gut während der Wartezeit soll was anderes getan werden Idee: erstes Zeichen zum Drucker dann Scheduler IAIK 31
Interruptgesteuerte I/O Drucker sendet Interrupt wenn für nächstes Zeichen bereit Interruptbehandlungsroutine stellt nächstes Zeichen zur Verfügung IAIK 32
Interruptgesteuerte I/O IAIK 33
I/O mit DMA Nachteil der Interrupt-Methode: Interrupts kosten Zeit DMA als Alternative DMA-Controller erledigt die Arbeit nur mehr ein Interrupt pro Puffer IAIK 34
I/O mit DMA IAIK 35
I/O-Schichtenmodell IAIK 36
I/O-Schichten IAIK 37
Interrupt-Handler Interrupts sollen möglichst unsichtbar bleiben Modell: Prozess blockiert bis Operation beendet und Interrupt auftritt Möglich beispielsweise durch Verwendung von down(s), wait(v) oder receive(m) IAIK 38
Interrupt-Handler Interruptbehandlung deblockiert Prozess up(s), signal(v) oder send(m) Ideal, wenn Treiber als Prozess ausgeführt was ist bei Interrupt alles zu tun (Achtung: plattformabhängig!) IAIK 39
Interrupt-Handler 1. Sicherung aller Register, die nicht schon durch Hardware gesichert 2. Aufbau des Kontext für Interruptbehandlung (kann initialisieren des TLB, der MMU und der Pagetables bedeuten) 3. Erzeugen eines Stacks für Interruptbehandlungsroutine IAIK 40
Interrupt-Handler 1. Kopieren der Register (des unterbrochenen Prozesses) in die Prozesstabelle 2. Interrupt-Controller informieren (interrupts wieder erlauben) 3. Interruptbehandlungsroutine aufrufen (lesen Infos der betroffenen Geräte aus) IAIK 41
Interrupt-Handler 1. Nächsten Prozess aussuchen 2. MMU-Kontext für neuen Prozess initialisieren 3. Laden der Prozessregister und PSW 4. Neuen Prozess starten IAIK 42
Gerätetreiber Jedes I/O-Geräte benötigt geräteabhängige Steuersoftware Treiber für jedes Betriebssystem unterschiedlich Treiber steuert meist Klasse ähnlicher Geräte IAIK 43
Treiber Muss auf HW Zugriff haben können daher normalerweise Teil des Betriebssystems möglich: Treiber im Userspace laufen lassen Systemcalls für Lesen / Schreiben der Geräteregister leider nicht der Fall IAIK 44
Gerätetreiber also Teil des Betriebssystems aber von Außenstehenden geschrieben erfordert klares Modell und klare Schnittstellen IAIK 45
Modell IAIK 46
Gerätetreiber-Kategorien Blockgeräte (block devices) zeichenorientierte Geräte (character devices) oft zwei Standardschnittstellen eine für alle Blockgeräte eine für alle zeichenorientierten Geräte IAIK 47
Struktur trad. Unix: eine große Objektdatei alle notwendigen Treiber enthalten neuer Treiber: BS neu übersetzen unpraktisch nicht jeder Benutzer kann das (speziell bei PC s) daher dynamisches Laden nötig IAIK 48
Aufgaben eines Treibers Bearbeiten von Schreib- und Lesebefehlen Initialisieren Energiemanagement Ereignisverwaltung IAIK 49
Treiberstruktur Prüfen der Eingabeparameter u.u. Übersetzung abstrakter in reelle Werte lineare Blockadresse Kopf/Spur/Sektor prüfen, ob Gerät frei nein: Anfrage speichern ja: prüfen, ob Anfrage durchführbar (z.b. Motor eingeschaltet) IAIK 50
Treiberstruktur Kontrolle: Sequenz von Befehlen an Controller schicken Befehl in Steuerregister schreiben dann im Statusregister prüfen, ob Befehl akzeptiert IAIK 51
Treiberstruktur Serie von Befehlen: einer nach dem anderen verkettete Liste in Speicher, Controller liest Befehle aus meist: warten, bis Befehl ausgeführt Blockieren manchmal: Befehl gleich erledigt IAIK 52
Treiberstruktur Wenn blockiert: irgendwann wieder aufgeweckt Untersuchen, ob Fehler aufgetreten eventuell Daten an aufrufende Software übergeben Statusinfo an Aufrufer übergeben IAIK 53
Treiberstruktur Treiber kann durch Interrupt des gesteuerten Geräts unterbrochen werden Treiber wird wieder aufgerufen muss daher reentrant (wiedereintrittsfähig sein) muss erwarten, dass er aufgerufen wird, bevor ein Aufruf beendet ist IAIK 54
Sonderfälle Treiber muss mit Entfernen des Gerätes umgehen können aktuelle I/O abbrechen wartende Anfragen entfernen alle Aufrufer informieren neue Geräte können dazukommen IAIK 55
Geräteunabhängige SW IAIK 56
Geräteunabhängige SW Teile der I/O geräteunabhängig durchführbar Funktionen (typisch) Einheitliches Interface Pufferung Fehlerbericht Anforderung/Freigabe von Geräten geräteunabhängige Blockgröße IAIK 57
Schnittstellen Eine Hauptaufgabe: einheitliche Darstellung unterschiedlicher I/O- Geräte und Treiber sonst BS bei jedem neuen Gerät neu anpassen! Interface Treiber/Betriebssystem ein Aspekt davon IAIK 58
Schnittstellen IAIK 59
Schnittstellen Einheitliche Schnittstellen Treiber leichter einbindbar Abbildung Namen Device allgemein möglich Unix: /dev/xxx special file major/minor device number identifiziert Gerät Schutzmöglichkeit über Standard- File-Mechanismen IAIK 60
Pufferung Generell wichtig Beispiel: Prozess will Zeichen von Modem lesen Strategie 1: ein Zeichen anfordern Blockieren IAIK 61
Pufferung Problem: pro Zeichen einmal Prozess starten viele Kontextwechsel. Ineffizient Variante 2: Prozess stellt Puffer (n Zeichen) zur Verfügung Lesebefehl für n Zeichen Erst wenn Puffer voll, Prozess aufwecken IAIK 62
Pufferung Effizienter Nachteile: Pufferspeicher darf nicht ausgelagert sein Seiten locken Wenn zu viele Seiten gelockt Menge der freien Seiten wird kleiner IAIK 63
Pufferung Strategie 3: Puffer im Kernelspace Wenn gefüllt: ev. Seite einlagern und Daten in Userspace kopieren IAIK 64
Pufferung Problem: Was tun, wenn Daten ankommen, während kopiert wird? Strategie 4: zweiter Puffer im kernel doppelte Pufferung IAIK 65
Pufferung bei Ausgabe N Zeichen an Modem Strategie 1: Prozess blockieren bis Daten weg kann lange dauern! Strategie 2: I/O parallel durchführen wie weiß Prozess, wann I/O fertig ist? Strategie 3: Daten in Kernel-Puffer kopieren und parallel bearbeiten IAIK 66
Fehlerbericht Fehler sind bei I/O häufig Viele Fehler gerätespezifisch müssen vom Treiber behandelt werden Wenn Treiber nicht weiß, was zu tun: Fehler an Software weiterreichen IAIK 67
I/O Software im User Space Kleinerer Teil, zt Bibliotheken I/O-Routinen (open, read, write, ) Formatierung (printf) Spooling-Systeme IAIK 68
Devices nur ausgewählte Teile Plattenspeicher Timer Terminals Energieverwaltung IAIK 69
Plattenspeicher Wesentliche Eigenschaft: Fehlertoleranz z.t. auf Filesystemebene nötig (plötzliches Abschalten) z.t. auf Hardwareebene IAIK 70
RAID Redundant Array of Inexpensive (Independent) Disks (Patterson 1988) mehrere zusammengeschaltete Platten, sieht für das System wie eine physische Festplatte aus IAIK 71
RAID 0 Festplatte in Strips zu k Sektoren teilen striping gut bei großen Anfragen Parallele Bearbeitung schneller Nachteil: Fehleranfällig IAIK 72
RAID 1 Platten werden dupliziert mirroring gute Ausfallssicherheit mit RAID 0 kombinierbar (RAID 0+1) IAIK 73
RAID 4 XOR mehrerer Strips Paritätsstrip Platte kaputt fehlende Bytes berechenbar Sicherheitsgewinn, kein Performancegewinn Parität muss neu berechnet werden (erfordert lesen der alten Daten und alten Parität) IAIK 74
RAID 5 verhindert Flaschenhals Parity-Platte Parity-Info auf alle Platten verteilt IAIK 75
Fehlerbehandlung Festplatten haben Defekte Fehlerhafte Sektoren: read(write(x))!= X Fehlerbehandlung im Controller im Betriebssystem IAIK 86
Fehlerbehandlung Controller: Liste fehlerhafter Sektoren auf Festplatte schreiben (Produktion) fehlerhafte Sektoren durch Reservesektoren ersetzen IAIK 87
Fehler im Betrieb transiente Fehler verursacht durch feine Staubpartikel erneutes Lesen funktioniert Sektor wird kaputt: auf Reservesektor ausweichen Verwaltung auch im Betriebssysem möglich IAIK 88
Stable Storage (Zuverlässiger Speicher) Festplatten können Fehler machen oder kaputt werden Weder Sicherungen noch RAID schützen vor Abstürzen beim Schreiben Manchmal wichtig, dass Daten nie verloren gehen geht nur mit Einschränkungen. IAIK 89
Stable Storage Eigenschaft: Schreibvorgänge werden korrekt oder nicht ausgeführt IAIK 90
Voraussetzungen Schreibvorgang korrekt oder falsch Fehler werden beim Lesen erkannt korrekt geschriebener Sektor kann spontan fehlerhaft werden Fehler auf einer Platte auf zweiter Platte frühestens nach Δt (1 Tag) Prozessor kann beliebig ausfallen Speicher kann 100% zuverlässig gemacht werden! IAIK 91
Stable Storage Paar identischer Festplatten korresponierende Blöcke bilden zusammen einen fehlerfreien Block kein Fehler: Beide Blöcke gleich Drei Operationen stable write stable read crash recovery IAIK 92
stable write Schreiben auf Laufwerk 1 Lesen und Überprüfen ev. bis zu n mal wiederholen eventuell Reservesektor Schreiben auf Laufwerk 2 wie oben, bis funktioniert IAIK 93
stable read lies Block von Laufwerk 1 falscher Fehlerkorrekturcode Lesen wiederholen (n mal) immer noch fehlerhaft: von Laufwerk 2 lesen Erinnerung: Annahme, dass nicht 2 Blöcke zum gleichen Zeitpunkt kaputt werden IAIK 94
crash recovery Nach Absturz: Durchsuchen beider Festplatten und Vergleich der Blöcke Blöcke ident: passt einer fehlerhaft: durch anderen überschreiben korrekt aber unterschiedlich: Block LW 1 über den von LW2 schreiben IAIK 95
Prozessorabstürze IAIK 96
Uhren wichtig für Funktion des Betriebssystems Uhrzeit ermöglicht preemption wie Gerätetreiber unterbricht in vorgegebenen Intervallen IAIK 97
virtuelle Adressen DMA-Controller verwendet physische Adressen Betriebssystem muss virtuelle Adressen umrechnen IAIK 98
warum Puffer im Controller? Prüfsummen Geräte liefern Daten in konstanter Geschwindigkeit Bus könnte aber nicht frei sein! IAIK 99
I/O-Design-Kriterien IAIK 100
Ziele von I/O-Software Geräteunabhängigkeit Programme sollten mit Daten von Festplatte, Band, CD, Diskette etc und das ohne Änderung sort < input > output egal wo input und output herkommen IAIK 101
Ziele von I/O-Software Einheitliches Namensschema unabhängig vom Gerät Unix: alles unter / Fehlerbehandlung möglichst Controller oder das Betriebssystem transiente Fehler transparent IAIK 102
I/O-Software synchron/asynchron I/O ist asynchron Software will aber bei read warten bis was da ist Pufferung Daten können nicht immer am Speicherziel abgelegt werden gemeinsam/exklusiv benutzbare Geräte IAIK 103
I/O-Durchführung Drei Arten Programmiert mit Interrupts mit DMA IAIK 104
Programmierte I/O Prozess will Zeichen am Drucker ausgeben Systemcall Drucker belegt return mit Fehler Prozess blockiert bis Drucker frei (Spooling) IAIK 105
Programmierte I/O IAIK 106
Programmierte I/O Betriebssystem kopiert Zeichen in Kernel-Puffer leichter adressierbar Warten bis Drucker verfügbar erstes Zeichen in Datenregister des Druckers Drucker bereit für zweites Zeichen? IAIK 107
Programmierte I/O IAIK 108
Programmierte I/O Nachteil: Prozessor belegt bis Drucken fertig ok, wenn Wartezeit zwischen den einzelnen Zeichen sehr klein Prozessor nichts anderes zu tun (z.b. embedded systems) in komplexeren Systemen nicht ok! IAIK 109
Interruptgesteuerte I/O Wartezeit zwischen den Zeichen lang programmierte I/O nicht gut während der Wartezeit soll was anderes getan werden Idee: erstes Zeichen zum Drucker dann Scheduler IAIK 110
Interruptgesteuerte I/O Drucker sendet Interrupt wenn für nächstes Zeichen bereit Interruptbehandlungsroutine stellt nächstes Zeichen zur Verfügung IAIK 111
Interruptgesteuerte I/O IAIK 112
I/O mit DMA Nachteil der Interrupt-Methode: Interrupts kosten Zeit DMA als Alternative DMA-Controller erledigt die Arbeit nur mehr ein Interrupt pro Puffer IAIK 113
I/O mit DMA IAIK 114
I/O-Schichtenmodell IAIK 115
I/O-Schichten IAIK 116
Interrupt-Handler Interrupts sollen möglichst unsichtbar bleiben Modell: Prozess blockiert bis Operation beendet und Interrupt auftritt Möglich beispielsweise durch Verwendung von down(s), wait(v) oder receive(m) IAIK 117
Interrupt-Handler Interruptbehandlung deblockiert Prozess up(s), signal(v) oder send(m) Ideal, wenn Treiber als Prozess ausgeführt was ist bei Interrupt alles zu tun (Achtung: plattformabhängig!) IAIK 118
Interrupt-Handler 1. Sicherung aller Register, die nicht schon durch Hardware gesichert 2. Aufbau des Kontext für Interruptbehandlung (kann initialisieren des TLB, der MMU und der Pagetables bedeuten) 3. Erzeugen eines Stacks für Interruptbehandlungsroutine IAIK 119
Interrupt-Handler 1. Kopieren der Register (des unterbrochenen Prozesses) in die Prozesstabelle 2. Interrupt-Controller informieren (interrupts wieder erlauben) 3. Interruptbehandlungsroutine aufrufen (lesen Infos der betroffenen Geräte aus) IAIK 120
Interrupt-Handler 1. Nächsten Prozess aussuchen 2. MMU-Kontext für neuen Prozess initialisieren 3. Laden der Prozessregister und PSW 4. Neuen Prozess starten IAIK 121
Gerätetreiber Jedes I/O-Geräte benötigt geräteabhängige Steuersoftware Treiber für jedes Betriebssystem unterschiedlich Treiber steuert meist Klasse ähnlicher Geräte IAIK 122
Treiber Muss auf HW Zugriff haben können daher normalerweise Teil des Betriebssystems möglich: Treiber im Userspace laufen lassen Systemcalls für Lesen / Schreiben der Geräteregister leider nicht der Fall IAIK 123
Gerätetreiber also Teil des Betriebssystems aber von Außenstehenden geschrieben erfordert klares Modell und klare Schnittstellen IAIK 124
Modell IAIK 125
Gerätetreiber-Kategorien Blockgeräte (block devices) zeichenorientierte Geräte (character devices) oft zwei Standardschnittstellen eine für alle Blockgeräte eine für alle zeichenorientierten Geräte IAIK 126
Struktur trad. Unix: eine große Objektdatei alle notwendigen Treiber enthalten neuer Treiber: BS neu übersetzen unpraktisch nicht jeder Benutzer kann das (speziell bei PC s) daher dynamisches Laden nötig IAIK 127
Aufgaben eines Treibers Bearbeiten von Schreib- und Lesebefehlen Initialisieren Energiemanagement Ereignisverwaltung IAIK 128
Treiberstruktur Prüfen der Eingabeparameter u.u. Übersetzung abstrakter in reelle Werte lineare Blockadresse Kopf/Spur/Sektor prüfen, ob Gerät frei nein: Anfrage speichern ja: prüfen, ob Anfrage durchführbar (z.b. Motor eingeschaltet) IAIK 129
Treiberstruktur Kontrolle: Sequenz von Befehlen an Controller schicken Befehl in Steuerregister schreiben dann im Statusregister prüfen, ob Befehl akzeptiert IAIK 130
Treiberstruktur Serie von Befehlen: einer nach dem anderen verkettete Liste in Speicher, Controller liest Befehle aus meist: warten, bis Befehl ausgeführt Blockieren manchmal: Befehl gleich erledigt IAIK 131
Treiberstruktur Wenn blockiert: irgendwann wieder aufgeweckt Untersuchen, ob Fehler aufgetreten eventuell Daten an aufrufende Software übergeben Statusinfo an Aufrufer übergeben IAIK 132
Treiberstruktur Treiber kann durch Interrupt des gesteuerten Geräts unterbrochen werden Treiber wird wieder aufgerufen muss daher reentrant (wiedereintrittsfähig sein) muss erwarten, dass er aufgerufen wird, bevor ein Aufruf beendet ist IAIK 133
Sonderfälle Treiber muss mit Entfernen des Gerätes umgehen können aktuelle I/O abbrechen wartende Anfragen entfernen alle Aufrufer informieren neue Geräte können dazukommen IAIK 134
Geräteunabhängige SW IAIK 135
Geräteunabhängige SW Teile der I/O geräteunabhängig durchführbar Funktionen (typisch) Einheitliches Interface Pufferung Fehlerbericht Anforderung/Freigabe von Geräten geräteunabhängige Blockgröße IAIK 136
Schnittstellen Eine Hauptaufgabe: einheitliche Darstellung unterschiedlicher I/O- Geräte und Treiber sonst BS bei jedem neuen Gerät neu anpassen! Interface Treiber/Betriebssystem ein Aspekt davon IAIK 137
Schnittstellen IAIK 138
Schnittstellen Einheitliche Schnittstellen Treiber leichter einbindbar Abbildung Namen Device allgemein möglich Unix: /dev/xxx special file major/minor device number identifiziert Gerät Schutzmöglichkeit über Standard- File-Mechanismen IAIK 139
Pufferung Generell wichtig Beispiel: Prozess will Zeichen von Modem lesen Strategie 1: ein Zeichen anfordern Blockieren IAIK 140
Pufferung Problem: pro Zeichen einmal Prozess starten viele Kontextwechsel. Ineffizient Variante 2: Prozess stellt Puffer (n Zeichen) zur Verfügung Lesebefehl für n Zeichen Erst wenn Puffer voll, Prozess aufwecken IAIK 141
Pufferung Effizienter Nachteile: Pufferspeicher darf nicht ausgelagert sein Seiten locken Wenn zu viele Seiten gelockt Menge der freien Seiten wird kleiner IAIK 142
Pufferung Strategie 3: Puffer im Kernelspace Wenn gefüllt: ev. Seite einlagern und Daten in Userspace kopieren IAIK 143
Pufferung Problem: Was tun, wenn Daten ankommen, während kopiert wird? Strategie 4: zweiter Puffer im kernel doppelte Pufferung IAIK 144
Pufferung bei Ausgabe N Zeichen an Modem Strategie 1: Prozess blockieren bis Daten weg kann lange dauern! Strategie 2: I/O parallel durchführen wie weiß Prozess, wann I/O fertig ist? Strategie 3: Daten in Kernel-Puffer kopieren und parallel bearbeiten IAIK 145
Fehlerbericht Fehler sind bei I/O häufig Viele Fehler gerätespezifisch müssen vom Treiber behandelt werden Wenn Treiber nicht weiß, was zu tun: Fehler an Software weiterreichen IAIK 146
I/O Software im User Space Kleinerer Teil, zt Bibliotheken I/O-Routinen (open, read, write, ) Formatierung (printf) Spooling-Systeme IAIK 147
Devices nur ausgewählte Teile Plattenspeicher Timer Terminals Energieverwaltung IAIK 148
Plattenspeicher Wesentliche Eigenschaft: Fehlertoleranz z.t. auf Filesystemebene nötig (plötzliches Abschalten) z.t. auf Hardwareebene IAIK 149
RAID Redundant Array of Inexpensive (Independent) Disks (Patterson 1988) mehrere zusammengeschaltete Platten, sieht für das System wie eine physische Festplatte aus IAIK 150
RAID 0 Festplatte in Strips zu k Sektoren teilen striping gut bei großen Anfragen Parallele Bearbeitung schneller Nachteil: Fehleranfällig IAIK 151
RAID 1 Platten werden dupliziert mirroring gute Ausfallssicherheit mit RAID 0 kombinierbar (RAID 0+1) IAIK 152
RAID 4 XOR mehrerer Strips Paritätsstrip Platte kaputt fehlende Bytes berechenbar Sicherheitsgewinn, kein Performancegewinn Parität muss neu berechnet werden (erfordert lesen der alten Daten und alten Parität) IAIK 153
RAID 5 verhindert Flaschenhals Parity-Platte Parity-Info auf alle Platten verteilt IAIK 154
Fehlerbehandlung Festplatten haben Defekte Fehlerhafte Sektoren: read(write(x))!= X Fehlerbehandlung im Controller im Betriebssystem IAIK 165
Fehlerbehandlung Controller: Liste fehlerhafter Sektoren auf Festplatte schreiben (Produktion) fehlerhafte Sektoren durch Reservesektoren ersetzen IAIK 166
Fehler im Betrieb transiente Fehler verursacht durch feine Staubpartikel erneutes Lesen funktioniert Sektor wird kaputt: auf Reservesektor ausweichen Verwaltung auch im Betriebssysem möglich IAIK 167
Stable Storage (Zuverlässiger Speicher) Festplatten können Fehler machen oder kaputt werden Weder Sicherungen noch RAID schützen vor Abstürzen beim Schreiben Manchmal wichtig, dass Daten nie verloren gehen geht nur mit Einschränkungen. IAIK 168
Stable Storage Eigenschaft: Schreibvorgänge werden korrekt oder nicht ausgeführt IAIK 169
Voraussetzungen Schreibvorgang korrekt oder falsch Fehler werden beim Lesen erkannt korrekt geschriebener Sektor kann spontan fehlerhaft werden Fehler auf einer Platte auf zweiter Platte frühestens nach Δt (1 Tag) Prozessor kann beliebig ausfallen Speicher kann 100% zuverlässig gemacht werden! IAIK 170
Stable Storage Paar identischer Festplatten korresponierende Blöcke bilden zusammen einen fehlerfreien Block kein Fehler: Beide Blöcke gleich Drei Operationen stable write stable read crash recovery IAIK 171
stable write Schreiben auf Laufwerk 1 Lesen und Überprüfen ev. bis zu n mal wiederholen eventuell Reservesektor Schreiben auf Laufwerk 2 wie oben, bis funktioniert IAIK 172
stable read lies Block von Laufwerk 1 falscher Fehlerkorrekturcode Lesen wiederholen (n mal) immer noch fehlerhaft: von Laufwerk 2 lesen Erinnerung: Annahme, dass nicht 2 Blöcke zum gleichen Zeitpunkt kaputt werden IAIK 173
crash recovery Nach Absturz: Durchsuchen beider Festplatten und Vergleich der Blöcke Blöcke ident: passt einer fehlerhaft: durch anderen überschreiben korrekt aber unterschiedlich: Block LW 1 über den von LW2 schreiben IAIK 174
Prozessorabstürze IAIK 175