Kapitel 3

1. Kapitel 3 • 3.1 Disks • 3.8 Journey of a Byte • 3.9 Buffer Management • 3.10 I/O in Unix

2. um einen richtigen Umgang mit Datei Design zu finden, geht es in diesem Kapitel darum, sich die unterschiedlichen Devices und das System anzuschauen, in dem man Dateien speichern und wiederfinden kann • es gibt eine eigene Disziplin genannt “File Structures”, da Dateien eben nicht nur im Speicher des Rechners gespeichert werden können • Secondary Storage Devices (Magnetic Tape, Disk) bringen andere Voraussetzungen mit als der Primärspeicher (Memory, RAM, Cache) • der Zugriff auf Sekundärspeicher beansprucht erheblich mehr Zeit • nicht jeder Zugriff geht auf gleiche Weise vor sich • ein gutes File Structure Design nutzt Wissen über die verschiedenen Performances um Daten so anzuordnen, dass Kosten, die durch den Zugriff entstehen, minimiert werden • in diesem Kapitel geht es um die Charakteristiken von Sekundärspeicher • Fokus auf die Hauptmedien Magnetplatten und Tapes • Fragestellung, welche Teile der Hardware und Software sind daran beteiligt, wenn ein Byte von einem Programm zu einer Datei oder einer Diskette (disc) gesandt wird • zum Ende werden wir uns wichtige Aspekte des File Management, vor allem das Buffering, genauer anschauen

3. 3.1 Disks • Disk drives gehören zu einer Kategorie von Devices, die man Direct Access Storage Devices nennt (DASDs) -> sie ermöglichen direkten Zugriff auf Daten • im Gegensatz zu Serial Devices, die andere große Kategorie von Sekundärspeicher, die nur seriellen Zugang zu Daten ermöglichen, etwa Magnetbänder • serieller Zugang heißt: ein Datum kann nur gelesen oder geschrieben werden, wenn alle Daten vorher der Reihe nach bereits gelesen oder geschrieben wurden • Magnetplatten (magnetic disks) gibt es in unterschiedlichen Ausführungen • hard disks sind die am meisten gebrauchten: hohe Kapazität bei geringen Kosten pro Bit • floppy Disks: günstig, dafür langsam und geringe Kapazität -> geeignet für Backup oder als Transportmittel von geringen Datenmengen • ablösbare, transportable Disks nutzen Einsätze / Kassetten, die mehrmals für ein Laufwerk verwendet werden können, sie ermöglichen auch direkten Datenzugang • nicht - magnetische disks, etwa optische Platten, werden zunehmend wichtiger als Sekundärspeichergeräte

4. 3.1.2 Organisationsformen von Disks • Information ist auf der Oberfläche von einer oder mehreren Platten gespeichert • die Anordnung ist so, dass die Information in aufeinanderfolgenden Tracks auf der Oberfläche der Disk gespeichert ist • Jeder Track ist häufig in eine Anzahl von Sektoren (sectors) aufgeteilt • Ein Sektor ist die kleinste adressierbare Einheit einer Disk • wenn eine read Anweisung ein bestimmtes Byte einer Datei betrifft, muss das Betriebssystem die korrekte Oberfläche, den Track und den Sektor finden, dann den gesamten Sektor in den buffer lesen und somit das betreffende Byte innerhalb dieses Buffers finden • disk drives haben mehrere Platten • Tracks formen einen Zylinder: gesamte Information eines Zylinders wird zugänglich ohne den Arm mit den Read / Write Heads zu bewegen (seeking), der sehr langsam ist

5. 3.1.2 Kapazitäten und Speicherplatz von Disks • von Hundertmillionen zu Billionen von Bytes • typische Disk: jede Platte hat zwei Oberflächen -> Anzahl Tracks / Zylinder ist die doppelte Anzahl der Platten • Anzahl der Zylinder = Anzahl der Tracks auf einer Oberfläche • jeder Track hat die gleiche Kapazität • Datenmenge, die ein Track aufnimmt und Anzahl der Tracks auf einer Oberfläche hängen davon ab, wie dicht Bits auf der Oberfläche gespeichert werden können • ein Zylinder besteht aus einer Gruppe von Tracksein Track wiederum besteht aus einer Gruppen von Sektoren • ein Sektor besteht aus einer Gruppe von Bytes

6. Track Kapazität = Sektoren pro Track x Bytes pro Sektor • Zylinder Kapazität = Track pro Zylinder x Track Kapazität • Drive Kapazität = Anzahl Zylinder x Zylinder Kapazität • angenommen wir wollen ein File mit 50.000 Data Records auf einer 2.1 Gigabyte kleinen Computerdisk speichern, die folgende Charakteristika hat: • Bytes pro Sektor: 512 • Sektoren pro Track: 63 • Tracks pro Zylinder: 16 • Zylinder: 4092 • wie viele Zylinder benötigt das File, wenn jedes Data Record 256 Bytes benötigt • jeder Sektor kann zwei Records aufnehmen -> 50.000 / 2 = 25. 000 Sektoren benötigt das File • ein Zylinder kann 63 x 16 = 1008 Sektoren aufnehmen, also benötigt das File 25.000 / 1008 = 24.8 Zylinder • es ist gut möglich, dass in dem Disk Drive diese 24.8 Zylinder nicht aufeinanderfolgend vorliegen, in diesem Fall muss die Datei über mehrere Zylinder verteilt werden

7. 3.1.3 Track nach Sektoren ordnen - zwei wesentliche Arten, Daten auf einer Disk zu organisieren: nach Sektoren oder nach User - definierten Blocks • Organisation nach Sektoren wird im Folgenden genauer untersucht Physikalische Anordnung von Sektoren • Sektoren sind benachbarte Segmente von fixer Größe auf einem Track, die ein File speichern • diese Art, Sektoren logisch zu beschreiben mag zutreffen, jedoch sollte man physikalisch anders mit Sektoren umgehen -> diese können häufig nicht nacheinander gelesen werden • nachdem der Disk Controller Daten gelesen hat, benötigt er häufig etwas Zeit diese zu verarbeiten bis er weitere Informationen aufnehmen kann wenn logisch aufeinanderfolgende Sektoren einer Datei auch physisch aufeinander folgten, so würde man vermutlich den Beginn des folgenden Sektors verpassen -> ein Sektor pro Umdrehung lesbar • Lösungsversuch: interleaving von Sektoren • zwischen logisch benachbarten Sektoren wird physikalisch ein Interval weiterer Sektoren platziert • man spricht von einem Interleaving Factor • mittlerweile gibt es 1:1 interleaving -> sukzessive Sektoren sind auch physikalisch benachbart, in einer einzigen Umdrehung kann ein ganzer Track glesen werden

8. Clusters • ein Programm greift auf File zu: File Manager muss korrespondierende physikalische Adressen zu logischen Parts der Datei finden • File Manager sieht Datei als Serie von Sektor - Clustern ein Cluster ist eine feste Anzahl von angrenzenden Sektoren • wenn ein gegebenes Cluster auf der Disk gefunden wurde, können alle Sektoren des Clusters gelesen werden • File Allocation Table: Zuordnung logischer Sektoren zu physischen Cluster • beinhaltet eine Liste aller Clusters in einer Datei • logisch geordnet im Sinne der Sektoren, die diese Cluster beinhalten • System Administrator kann festlegen, wie viele Sektoren in einem Cluster zu sein haben, i.d.R. wenn die Disk initialisiert wird -> default: 3512 - byte Sektoren pro Cluster, Cluster Größe kann von 1 bis 65535 Sektoren reichen • Cluster representieren physikalisch aufeinanderfolgende Gruppen von Sektoren -> größere Cluster lesen mehrere Sektoren ohne weitere Suche ein File kann sequentiell gelesen werden • es geht also darum, die Suchvorgänge zu minimieren

9. Extents • eine Datei besteht aus einem Extent, wenn sie aus aufeinanderfolgenden (physikalischen) Clustern besteht -> alle Sektoren, Tracks, evtl Zylinder folgen sequentiell aufeinander • wenn nicht genügend Speicherplatz vorhanden ist um ein Extent zu bilden, so wird das File in zwei oder mehr Teile aufgeteilt und jeder davon bildet einen Extent • wenn neue Cluster zu einem File hinzugefügt werden, versucht der File Manager zunächst, sie an ihre Nachbarn anzuhängen wenn hier nicht genügend Platz besteht, so fügt der Manager neue Extents hinzu -> je mehr Extents, desto verteilter ist das File auf der physikalischen Disk -> weitere Suchvorgänge

10. Fragmentierung • jegliche Sektoren eines Drive müssen die gleiche Anzahl Bytes enthalten • Beispiel: Größe eines Sektors 512 Bytes, Größe eines Records in einem File 300 Bytes • ein Record pro Sektor speichern:man findet Rekord indem man einen Sektor sucht • jedoch bleibt Speicher ungenutzt -> internal fragmentation • über mehrere Sektoren verteilen • es geht kein Speicher verloren • jedoch werden einige Records über zwei Sektoren verteilt sein • Cluster als die kleinste Speichereinheit für ein File -> bieten ebenso die Gefahr der Fragmentierung und zwar, wenn die Anzahl der Bytes in einer Datei nicht ein exaktes Vielfaches eines Clusters ist

11. 3.1.4 Track nach Blocks ordnen • disk tracks können in Blocks unterteilt werden, deren Größe variiert • Blocks: feste oder variierende Größe • physikalische Records, in diesem Fall die kleinste Dateneinheit, welche ein Betriebssystem unterstützt • eine Organisation nach Blocks variiert in der Größe und lässt sich damit an die logische Ordnung von Daten anpassen • ein Block: speichert gewöhnlich ganzzahlige Anzahl von logischen Records • blocking factor: Anzahl der Records, die in jedem Block eines Files gespeichert werden • Beispiel: Datei mit 300 Byte Records -> über Block - addressing Schema kann man einen Block definieren, der ein Mehrfaches von 300 Bytes groß ist, je nach Bedarf • wenn es also wichtig ist, dass die physikalische Abbildung von Records ihrer logischen Organisation entspricht, dann sind Blocks nützlich • subblocks: - enhalten weitere Information über den Datenblockwerden Block beigefügt • count subblock: enhält Byte - Anzahl des entsprechenden Blocks • key subblock: Schlüssel für letztes Record im Block -> Suche anhand des Schlüssels

12. 3.1.5 Nondata Overhead • Blocks und Sektoren benötigen beide einen gewissen Speicherplatz für den nondata Overhead • Overhead: Information, die auf der Disk während der Formattierung gespeichert wurde • Sektor - adressierbare Disks:am Beginn jedes Sektors wird die Sektor - Adresse, Track Adresse und die Kondition des Sektors (brauchbar oder defekt) gespeichert • Lücken und Synchronisationsmarken werden zwischen Informationsfeldern platziert um dem read/write Mechanismus bei der Unterscheidung zu helfen • nondata Overhead ist nicht von Bedeutung für den Programmierer • die Sektorgröße für einen Drive bezeichnet auch etwa die Datenmenge, die ein Sektor aufnehmen kann • Block - organisierte Disks:Teile des Nondata Overhead sind unsichtbar für den Programmierer • aufgrund von Subblocks und Lücken zwischen Blocks gibt es bei Block - organisierten Disks etwas mehr nondata Information • auch da Größe und Anzahl von Blocks der unterschiedlichen Anwendungen variieren, kann auch der Speicherplatz des Overhead unterschiedlich groß sein

13. 3.1.6 Cost of a Disk Access • Access kann eingeteilt werden in drei distinkte physikalische Operationen, jede mit eigenem Zeitaufwand: • Seek Time, also der Suchvorgang • Rotational Delay, Verzögerung der Disk • Transfer Time, Übertragungszeit

14. Seek Time • Zeit, die benötigt wird, den Read/Write Arm zum korrekten Zylinder zu bewegen • abhängig davon, wie weit man den Arm bewegen muss • bei sequentiellem Zugang zu einem File, welches in konsekutiven Zylindern gespeichert ist: alle Tracks folgen aufeinander und der Read/Write Head bewegt sich am Ende nur um einen Track • wenn wir auf zwei Sektoren von zwei Files zugreifen wollen, die an gegensätzlichen Enden der Disk aufgehoben sind, ist der Suchvorgang sehr aufwendig • Mehrbenutzerumgebung ist generell aufwendiger -> mehrere Prozesse nutzen die Disk zur gleichen Zeit • man versucht gewöhnlich, eine durchschnittliche Suchzeit für eine besondere File Operation zu benennen • die durchschnittliche Suche geht über ein Drittel der Gesamtanzahl der Zylinder • Hard Disk durchschnittliche Seek Time: weniger als 10 Millisekunden

15. Rotational Delay • Zeit, die Disk benötigt so zu rotieren, dass der Sektor, nach dem man sucht, sich unter dem Read/Write Head befindet • gewöhnliche Rotationsgeschwindigkeit: 5000 rpm, dh eine Umdrehung pro 12 Millisekunden • Im Durschnitt liegt die Verzögerung bei einer halben Umdrehung, das heißt bei 6 Millisekunden • Floppy Disks: 83.3 Millisekunden • Im Fall des Seeking gelten diese Durchschnittswerte nur, wenn der Read/Write Head von einer beliebigen Stelle zum Zieltrack geht • in vielen Fällen kann die Verzögerung sehr viel geringer sein als der Durchschnittswert

16. Transfer Time • wenn die Daten unter dem Read/Write Head liegen, können sie übertragen werden • die Übertragungszeit ist durch folgende Formel gegeben: • Transfer Time = number of bytes transferred / number of bytes on a track x rotation time • wenn ein Drive in Sektoren aufgeteilt ist, hängt die Transferzeit für einen Sektor von der Anzahl der Sektoren auf einem Track ab • Some Timing Computations • zwei unterschiedliche File Processing Situationen • A: sequentieller Access eines Files -> wir nutzen so viel vom File, wie wir können, jedes Mal, wenn wir es erreichen • B: alle Records eines Files in beliebiger Reihenfolge angehen -> wir können bei jedem Zugang nur ein Record nutzen

17. Grundlage: High Performance Seagate Cheetah 9 Gigabyte Disk • höchste Performance: wenn Files in One Track Einheiten eingeteilt sind • Sektoren haben interleaving Faktor 1 • wie lange dauert es, ein 8704000 Byte File zu lesen, welches in 34.000 256-byte Rekords unterteilt ist? • File wird als eine Sequenz von 2125 4096-byte Sektoren gespeichert -> diese sind auf 100 Tracks verteilt • Disk benötigt 100 Tracks um die 8074 KB zu speichern -> diese sind über die Oberfläche verteilt • Zeit für A: • Average Seek: 8msec • Rotational Delay: 3msec • Read one Track: 6 msec • Total: 17 msec • Finden und lesen von 100 Tracks -> 100 x 17 msec = 1.7 sec • Zeit für B: • Average Seek: 8msec • Rotational Delay: 3msec • Read one Cluster: 0.28 msec • Total: 11.28 msec • Total time = 34.000 x 11.28 msec = 9.25 sec-> Bedeutung der Suchzeit

18. 3.1.8 Disk as Bottleneck • Im Gegensatz zu Disk Geschwindigkeit, nimmt Disk Performance stätig zu • High Performance Disk Drive mit 50 KB pro Track kann eine Höchstrate von 5MB pro Sekunde übertragen, High Performance Networks können mehr als 100 MB pro Sekunde übertragen • dies bedeutet, dass ein Prozess häufig Disk Bound / Disk gebunden läuft • das Netzwerk und Computer Central Processing Unit, also CPU müssen auf die Disk warten • eine Technik, die dies zu lösen versucht ist Multiprogramming: CPU bearbeitet andere Prozesse während sie auf die Disk wartet, was nicht immer möglich ist • weitere Technik: striping -> File wird auf mehrere Drives aufgeteilt, so dass diese an das Netzwerk gleichzeitig mehrere Teile des Files überbringen • etwas genereller: Parallism -> wenn immer es zu einem Flaschenhals im System kommt, so verdoppele die zuständige Einheit, so dass mehrere davon gleichzeitig arbeiten können • unabhängige Prozesse interferieren nicht, jedoch verbessern parallel verlaufende Prozesse auch nicht die Schnelligkeit eines Prozesses bzw eines einzigen Drives

19. RAID • jeden Block auf mehrere Drives verteilen -> erhöht dessen Bearbeitungszeit • 8 - Drive RAID: der Controller erhält einen Block zu schreiben und bricht diesen in acht Teile, jeden mit genügend Daten für einen Track • das erste Stück wird auf einen Track der ersten Disk geschrieben, das zweite auf den gleichen Track auf der zweiten Disk usw. • read: der gleiche Track wird jeweils von den unterschiedlichen Disks gelesen • im Cache wird der Block zusammengefügt und von dort in den I/O Channel transferiert • RAM: • Disk Drive wird gar nicht benutzt • Speicher Disks und CacheSpeicher, der das Verhalten einer mechanischen Disk simuliert • volatil, dh Daten sind verloren, wenn der Rechner ausgeschaltet wird • ein Beispiel für buffering

20. Cache: • enthält Seiten (pages) von Datenfile • manager schaut zunächst hier nach, ob die jeweilige Seite von Daten sich im Cache befindet, bevor er Sekundärspeicher anfragt • sind die Daten im Cache, können sie sofort bearbeitet werden, andernfalls liest der File Manager die Daten von der Disk • arbeitet besonders vorteilhaft in der Performance wenn Daten Access Muster eine hohe Lokalität aufweisen -> locality: Blocks, die zeitlich dicht beieinander bearbeitet werden, werden benachbart auf der Disk gespeichert • bei Blocks, die auf der Disk nah beieinander sich befinden, ist es sehr wahrscheinlich, dass sie zur Page oder den Pages gehören, die in einem einzigen Read - Vorgang bearbeitet werden -> dies vermeidet weitere Zugriffe

21. Journey of a Byte • Was passiert, wenn ein Programm ein Byte in ein File auf einer Disk schreibt?wir wissen, dass das Programm eine write - Funktion aufruft • wir wissen auch in etwa, wie ein Byte auf der Disk gespeichert wird • aber was passiert zwischen Programm und Disk? • angenommen wir wollen den Buchstaben p in einer Character Variablen (ch) in ein File namens textfile schreiben • dazu schreiben wir das statement: write (textfile, ch, 1) • write statement ruft Betriebssystem -> dieses muss die Reise des Bytes überwachen • wenn einmal das Betriebssystem diese Aufgabe übernommen hat, liegt die Kontrolle nicht mehr beim Programm

22. 3.8.1 File Manager Betriebssystem -> mehrere Programme, jedes davon um einen anderen Teil der Ressourcen zu verwalten • File Manager -> dies sind nun die Programme zusammen gefasst, die sich um Dateien und Ein- und Ausgabeprozesse kümmern • diese Programme bzw. der File Manager kann gedacht werden als mehrere Prozessebenen, von denen die oberen sich eher mit symbolischen, dh logischen Aspekten befassen und die unteren mit physischen Aspekten der Datenverwaltung • jeder Layer, also jede Ebene / Schicht, ruft die darunter liegende auf • ist die unterste Ebene erreicht, so wird das Byte auf die Disk geschrieben • zunächst überprüft der File Manager, ob die logischen Charakteristiken der Datei konsistent mit der Aufgabe sind • File Manager sucht das File in einer Tabelle -> hier werden Eigenschaften der Datei aufgezeigt -> Besitzer, Format/Typ, Zugriffsrechte • wenn p an das Ende des Files geschrieben werden soll, muss der File Manager heraus finden, wo die Datei endet -> (physikalischer) Ort im Speicher, wo der letzte Sektor der Datei endet -> File Manager findet diesen über File Allocation Table (FAT) -> Drive, Zylinder, Track, Sektor

23. 3.8.2 The I/O Buffer • File Manager legt fest, ob der betreffende Sektor, in dem das Byte zu speichern ist, sich schon im Speicher befindet oder erst dort hinein geladen werden muss • wenn der Sektor geladen werden muss, muss File Manager einen verfügbaren Ein/Ausgabebuffer finden, wo Platz für den Sektor ist • wenn der Sektor im Buffer ist, kann der File Manager das p an seine Position setzen • der I/O Buffer erlaubt es dem File Manager, Daten in Sektor- oder Block-organisierten Einheiten zu lesen und zu schreiben -> stellt sicher, dass Organisation der Daten im Speicher genauso wie auf der Disk • bevor der Sektor zur Disk gesendet wird, überprüft der File Manager, ob noch mehrere Bytes in diesen Sektor geschrieben werden müssen • so kann es durchaus sein, dass p noch eine Weile im Speicher liegt bevor es auf die Disk geschrieben wird

24. 3.8.3 Das Byte verlässt den Speicher - I/O Processor und Disk Controller • alle Byte Operationen fanden bisher im Primärspeicher statt und wurden vermutlich von der CPU ausgeführt • alle kommenden Datenpfade werden etwas langsamer sein als die im Primärspeicher • Flaschenhals: durch diese Unterschiede kann es dazu kommen, dass das Byte warten muss, bis ein externer Datenpfad frei wird • die CPU ihrerseits hat Zeit, Informationen in entsprechend kleine Chunks zu verpacken und mit entsprechender Geschwindigkeit zu versenden, so dass externe Geräte sie behandelt können • häufig kann CPU zu mehreren externen Geräten gleichzeitig Informationen verschicken • diese Byte Prozesse - das heißt, Bytes zu Gruppen zusammen zu fügen, um sie empfangen bzw verschicken zu können und mit externen Geräten auszutauschen - sind außerordentlich aufwendig, so dass die CPU, die für alle möglichen Prozesse zuständig ist, nicht ihre Ressourcen daran verschwenden soll • daher gibt es eine besondere Einheit dafür - den I/O Prozessor

25. I/O Prozessor : • kann alles sein von einem Chip, der nur ein Byte aufnimmt, bis zu einem kleinen hochkomplexen Computer, der mit mehreren Geräten simultan kommuniziert • bekommt Anweisungen vom Betriebssystem -> wenn er diese übernommen hat, arbeitet er selbstständig und erleichtert so das Betriebssystem und die CPU von der Kommunikation mit Sekundärspeichergeräten • somit können sich I/O Prozesse und interne Operationen überschneiden, dh gleichzeitig ausgeführt werdender File Manager kontaktiert den I/O Prozessor, wenn Daten im Buffer sind, die zur Disk gesendet werden sollen -> wie viele Daten, wohin sie geschrieben werden sollen kommt etwa in Form eines Programms, welches das Betriebssystem schreibt und der I/O Prozessor ausführt

26. Disk Controller: • Disk Operationen überprüfen • I/O Prozessor sendet Anfrage an Disk Controller, ob der gesuchte Drive zum Schreiben verfügbar ist der Disk Drive wird angewiesen, den Read/Write Head zu dem Track und Sektor zu bewegen, wo das Byte gespeichert werden sollder Read/ Write Head muss nun den richtigen Track suchen und warten bis die Disk sich so gedreht hat, dass der gewünschte Sektor sich unter dem Head befindet -> sind Track und Sektor gefunden, kann der I/O Prozessor die Bytes versenden, eins nach dem anderen • die acht Bits eines Bytes werden nacheinander auf der Oberfläche der Disk platziert • 3.9 Buffer Management • Buffering als ein wichtiger Aspekt der Kommunikation zwischen Programm und Sekundärspeicher

27. 3.9.1 Buffer Bottlenecks • File Manager findet I/O Buffer, die groß genug sind um alle Daten aufzunehmen, es kann zudem sein, dass der File Manager auch mehrere Buffer aktiviert für einen I/O Prozess • etwa wenn ein Programm gleichzeitig ein Zeichen anfordern und heraus geben will • wenn das Programm nach dem ersten Zeichen fragt, wird der I/O Buffer mit dem Sektor, der das Zeichen enthält beladen und das Zeichen wird an das Programm geleitet • wenn das Programm dann entscheidet, ein Zeichen heraus zu geben, wird der I/O Buffer wiederum mit dem Sektor beladen, in welches das Zeichen geschrieben werden soll und zerstört dabei das erste Byte • aus diesem Grund haben I/O Systeme generell mindestens zwei Buffer, einen für Input, einen für Output • wir hatten bereits über die Geschwindigkeitsunterschiede des internen und externen Memorys gesprochen und darüber, dass die CPU viel Zeit damit verbringt auf I/O Prozesse zu warten - ein Programm, welches aus diesen Gründen an Geschwindigkeit verliert nennen wir I/O Bound

28. 3.9.2 Buffering Strategies • Multiple Buffering • Double Buffering: • es gibt zwei Buffer, einer wird von der CPU gefüllt, der Inhalt des anderen wird auf eine Disk geschrieben - dann werden die Rollen getauscht • diese Technik des Rollentauschs kann auch auf mehr als zwei Buffer angewendet werden • die Organisation der Buffer wird vom Betriebssystem erledigt Buffer Pooling • Buffer wird aus einem Pool verfügbarer Buffer gesucht • nach unterschiedlichen Kriterien ausgewählt • etwa nach dem Schema: es wird der am längsten ungenutze Buffer gewählt • die Buffer kommen in eine Queue, so können alle Buffer ihren Inhalt behalten bis die vorderen Buffer genutzt wurden • somit kann das System in den Buffern mit Inhalt suchen, ob ein bestimmter Sektor oder Block, der gesucht wird, bereits enthalten ist • least recently used : ist ein häufig verwendetes Konzept und hängt mit der Annahme zusammen, dass ein Datenblock, der gerade genutzt wurde, eher in näherer Zukunft nochmal gebraucht wird als ein Datenblock, der vor längerer Zeit gebraucht wurde

29. Move Mode and Locate Mode • Move Mode: wenn Daten immer von System Buffer zu Programm Buffer kopiert werden müssen, ist die Zeit, die ein “Move” benötigt entscheidend • Move Mode kann umgangen werden - wenn der File Manager I/O Prozesse direkt vom Sekundärspeicher zum Speicherbereich des Programms ausführen kann, ist kein extra “Move” notwendig • andernfalls könnte der File Manager die System Buffer für I/O Prozesse nutzen und dem Programm lediglich deren Speicheradressen übergeben, über Pointer Variablen • Locate Mode: Programm ist in der Lage, direkt auf I/O Buffern zu arbeiten ohne dass ein Datentransfer zwischen I/O Buffer und Programm Buffer nötig ist • Scatter / Gather I/O • wenn man etwa Daten und Header innerhalb eines Blocks trennen möchte, könnte man den ganzen Block zunächst in einen Buffer einlesen, dann die unterschiedlichen Teile - Information und Header - in unterschiedliche Buffer laden • diesen umständlichen Prozess kann man über Scatter Input verkürzen -> ein einziger Read - Aufruf spricht mehrere Buffer an, in welche Daten eines Blockes “(ge)scattered” werden • Gather Output: mehrere Buffer werden versammelt und gefüllt mit einem einzigen Write - Aufruf • unterschiedliche Buffering Techniken müssen zunächst ausfindig gemacht werden -> durch Kommunikation mit dem Betriebssystem oder durch unterschiedliche Strukturierung von Programmen

30. I/O in Unix • die Reise des Bytes zeigt uns, dass man Eingabe / Ausgabe als einen Prozess bzw ein Durchlaufen mehrerer Layers, über mehrere Ebenen betrachten kann • Unix stellt ein gutes Beispiel dafür dar, wie diese verschiedenen Ebenen in einem Betriebssystem vorkommen • es geht im Folgenden darum, ein paar Unix Features vorzustellen, damit die beschriebenen Aspekte nochmal deutlicher werden • darüber hinaus um sich mit Unix - Terminologie vertraut zu machen

31. 3.10.1 Betriebssystemkern (The Kernel) • der Prozess, Daten von einem Programm zu einem externen Gerät zu transferieren, kann als ein Durchlaufen durch eine Serie von Ebenen (Layers) gesehen werden • die oberste Ebene behandelt Daten in ihrer logischen Struktur -> man speichert in einem File einen Namen, einen Text, einen Integer Array oder eine andere logische Entität • diese Sicht hat eine Anwendung von dem, was sich in einem File befindet • die folgenden Ebenen haben die Aufgabe, die logischen Objekte in eine Reihe Bits auf einem physikalischen Gerät zu transformieren • oberste Ebene in Unix: Prozesse, die auf logischen Einheiten arbeiten und Probleme behandeln wie das Zählen von Worten in einer Datei • Shell Routine • User Programme, die auf Dateien operieren • Library Routines wie scanf oder fread • unterhalb dieser Ebene ist der Betriebssystemkern, der sämtliche weitere Layer beinhaltet -> hier wird auf Bytes operiert und alle logischen Annahmen und Einteilungen sind hier irrelevant -> Operationen sind also unabhängig von der logischen Einteilung einer Anwendung

32. die Reise eines Bytes durch den Betriebssystemkern • etwa wenn wir ein Zeichen auf die Disk schreiben wollen • das Programm führt einen Systemaufruf aus: • write (fd, &ch, 1); • hier wird der Kern sofort aufgerufen • Routinen, die Prozesse direkt mit dem Betriebssystemkern kommunizieren lassen, bilden das System Call Interface • ein System Aufruf weist den Betriebssystemkern an, das Zeichen an ein File zu schreiben • der Betriebssystemkern beginnt damit, den File Descriptor des Programms mit einem File oder Gerät zu verbinden im File System • Dies geschieht durch 4 Tabellen, die den Betriebssystemkern dazu befähigen, seinen Weg zu den Speicherplätzen auf der Disk zu finden, die das File speichern die 4 Tabellen sind:

33. eine File Descriptor Tabelle • eine Open File Tabelle, die Informationen über offene Files enthält • die File Allocation Tabelle, die Teil einer Struktur ist, die man Index Node nennt • eine Tabelle mit Index Nodes, mit einem Eintrag über jedes File, welches gerade in Gebrauch ist • die Tabellen werden von der I/O des Betriebssystemkern kontrolliert, sind aber eigentlich in anderen physikalischen Teilen verortet • die File Descriptor Tabelle gehört zum Programm • die Open File Tabelle und Index Node Tabelle gehören zum Betriebssystemkern • ein Index Node gehört zum File System • die 4 Tabellen werden vom Kern kontaktiert, die Informationen bereit zu stellen, die gebraucht werden um das File auf die Disk zu schreiben • File Descriptor Table: • verbindet jeden der File Descriptors mit einem Eintrag in der Open File Tabelle • jeder Prozess hat seine eigene File Descriptor Tabelle • diese beinhaltet Einträge für alle Files, die vom Prozess geöffnet wurden, eingeschlossen der “Files” stdin, stdout, stderr

34. Open File Table: • enthält Einträge über offene Files • jedes Mal wenn ein neues File geöffnet oder produziert wird, wird ein neuer Eintrag zur Open File Table hinzugefügt • Einträge: File Structures -> enthalten Informationen, wie das File behandelt werden kann • enthält zudem einen Array mit Zeigers zu generischen Funktionen, die auf Files operieren können -> je nach Typ des Files unterschiedlich • mehrere unterschiedliche Prozesse können auf den gleichen Eintrag in der Open File Tabelle verweisen • wenn jedoch das gleiche File von zwei separaten Open Statements geöffnet wird, werden zwei Einträge in der Tabelle gemacht und die beiden Prozesse operieren unabhängig auf dem File • Information ist transitorisch • gibt Kern Information darüber, was mit dem File gemacht werden kann • Kern benötigt mehr Informationen über File -> Index Node oder INode

35. Index Node / Inode • eher eine permanente Struktur • File Structure existiert so lange wie ein File geöffnet und zugänglich ist • INode existiert so lange wie das File selbst • INode wird mit dem File auf der Disk gespeichert • wird File geöffnet, wird eine Kopie der Index Node in den Speicher geladen -> dort in INode Table • in INode: eine Liste / Index der Blocks, aus denen File besteht • diese Liste ist die Unix Version von einer File Allocation Table • wenn der Kernel die INode Informationen hat, hat es alle benötigte Informationen zum File und ruft ein I/O Prozessor Programm auf, welches auf den Filetyp passt -> Device Driver

36. 3.10.2 Linking File Names to Files • wie wird der File Name zum entsprechenden File verlinkt • alle Referenzen zu Files beginnen mit einer Directory -> in diesen werden File Names gespeichert • Eine Directory: selbst ein kleines File, welches für jedes File den File Namen und den entsprechenden Zeiger zur Inode des Files auf der Disk enthält • dieser Zeiger wird hard link genannt -> stellt direkte Referenz von File Name zu aller weiterer Information zum File dar • File wird geöffnet -> Hard Link wird gebraucht um INode ins Memory zu laden und um einen Eintrag in Open File Tabelle vorzunehmen • ein File - mehrere Namen: mehrere File Namen zeigen auf die gleiche INode, diese speichert die Anzahl der Zeiger • File Name wird gelöscht - File selbst nicht, sondern nur der Hard Link Counter wird dekrementiert • Soft Link oder Symbolic Link: verlinkt einen File Namen zu einem anderen File Namen -> Pfad zu einer Datei

37. 3.10.3 Normal Files, Special Files, Sockets • “Everything is a file” Konzept in Unix • Betriebssystemkern unterscheidet drei Typen von Files: • Normal Files • Special Files: repräsentieren einen Zeichenstrom und Kontrollsignale, die ein Gerät steuern wie etwa ein Graphic Device • Sockets: Abstraktionen, die als Endpunkte von Kommunikationen zwischen Prozessen gelten • 3.10.4 Block I/O • drei Filetypen erhalten durch drei verschiedene I/O Systeme Zugang zu Geräten: Block I/O System, Character I/O System, Network I/O System • Block I/O in Unix = File Manager • behandelt Transport von normalen File Daten zu einer Block - organisierten Disk oder Tape • Block Device in Unix: adressierbarer Array von Blocks fixer Größe (etwa 512 Bytes)

38. 3.10.5 Device Drivers • für jedes periphere Device gibt es eine andere Routine = Device Driver, die Ein und Ausgabe zwischen Buffer und Device regelt • ein Device Driver entspricht etwa einem I/O Prozessor Programm • Block I/O System sieht peripheres Gerät als Array von physikalischen Blocks, adressierbar als Block 0,1,2, ... • Device Driver: nimmt einen Block aus dem Buffer und platziert diesen am richtigen Speicherort auf dem peripheren Device • Block I/O des Kernels muss somit nichts über dieses Device wissen • 3.10.6 Kernel und File System • Unix File System ist eine Sammlung von Dateien, gemeinsam mit dazugehöriger Information über diese Files • inkludiert Directory Structures, Directories, Files und Inodes • das File System ist zwar Teil des Kernels, sitzt aber physikalisch getrennt von diesem auf der Disk, während Kernel im Primärspeicher seine Arbeit verrichtet • somit ist die Organisation des File Systems unabhängig vom Kernel, zudem kann der gleiche Kernel auf unterschiedliche File Systeme zugreifen, die ihrerseits verschieden organisiert sind

39. 3.10.7 Magnetic Tape and Unix • eine Art Waisenkind in Unix I/O • Magnetic Tape Einheit hat Ähnlichkeiten mit block devices (block orientiert, radomly) und mit character devices (sequentieller Zugang), passt aber nicht ausschließlich in eine der beiden Kategorien • wird aber als block device behandelt, jedoch müssen auf ein Tape Blocks sequentiell geschrieben werden, nicht wahllos wie zu einer Disk • somit ist nur eine Write Anfrage erlaubt • wenn High Performance I/O benötigt: Character Device Interface kann genutzt werden um Daten sequentiell zu schreiben, dieser übergeht die Ordnung der Daten in einzelne Blocks