Unix Mechanismen II. VL Systemprogrammieren. Bernhard Huber SS 2008

Transkript

1 Unix Mechanismen II VL Systemprogrammieren Bernhard Huber SS 2008

2 Inhalt UNIX Kernel Filesystemverwaltung Peripherieverwaltung Networking 2

3 Begriffsdefinition UNIX eingetragene Marke (Open Group) für zertifizierte Mehrbenutzerbetriebssysteme die auf dem AT&T Original basieren Vortrag bezieht sich auf allgemeine Konzepte, die in UNIX-ähnlichen Systemen (BSD, Linux, etc.) ebenso gültig sind (Bezeichnung: Unix-Systeme) 3

4 Kernel Kernel ist Bezeichnung für den Betriebssystemkern in Unix-Systemen Kernel ist speziell angepasst für unterschiedliche Computer bzw. Computerarchitekturen (früheres manuelles Anpassen des Kernels an Spezialhardware wird meist durch automatisches Nachladen von Modulen autoload umgangen) 2 Arten von Unix Kernel: Micro Kernel Monolithic - Kernel 4

5 Micro Kernel Nur grundlegende Verwaltungsfunktionen tatsächlich im Kernel (z.b. Speicher- u. Prozeßverwaltung sowie grundlegende Mechanismen zur Interprozesskomm.) Weitere Funktionalität (z. B. Peripherie- oder Filesystemverwaltung) als Prozesse in die Benutzerebene ausgelagert Vorteile: klares Schnittstellendesign erzwungene modulare Programmierung; einfachere Portierbarkeit aufgrund guter Kapselung des Hardware-abhängigen Codes; bessere Zugriffsrechteverwaltung für Treiber (da in Benutzerebene) Nachteile: erhöhter Bedarf an Interprozeßkommunikation (auch zw. Kernel- Ebene und Benutzerebene Performance); I/O Zugriff schwieriger Vertreter: Minix, Mach 5

6 Monolithic Kernel Sämtliche Aufgaben des Betriebssystemkerns sind im Kernel (also im privilegierten Modus) realisiert vor allem auch I/O Treiber Zugriff von Applikationsprogrammen zu Kernelfunktionen (z.b. Treiber) über spezielles API (z.b. syscalls in Linux) Vorteile: effiziente Kommunikation zwischen Treibern Nachteile: I/O Treiber laufen im privilegierten Modus Risiko für System- Zuverlässigkeit; Austausch von Kernelfunktionen (z.b. Anpassung an neue Hardware) schwieriger Vertreter: Linux, Solaris, BSD Kernel-Module: Versuch den Nachteil der Inflexibilität von monolithischen Kernels gegenüber Micro Kernels zu mindern dynamisches Laden von Modulen, kompilieren einzelner Module 6

7 Kernel Versionsmanagement (Linux) Zwei Arten von Linux Kernels: stable kernel development kernel Regelung seit Juli 2004 ausgesetzt keine Kernelversion 2.7; Änderungen werden direkt in Version 2.6 eingepflegt neue Funktionalität wird im -mm Kernel getestet (Kernelpatch der aktuellen Version) Einführung einer 4. Zahl in der Kernelversion, um Bugfixes anzuzeigen (aktuell ) 7

8 Struktur des Kernels (Linux) 8

9 Aufgaben des Kernels Prozessverwaltung Interprozesskommunikation Speicherverwaltung Filesystemverwaltung Peripherieverwaltung Networking 9

10 Aufbau des Filesystems Hierarchische Struktur von Dateien Verschiedenste Dateitypen in einer gemeinsamen Verzeichnisstruktur everything is a file /root /bin /dev /etc /usr /var commands devices startup and configuration files /lib /man /local plain files (stream of characters) directories (Interpretation durch das OS) character-, block special files (Geräte; z.b. Terminal, Festplatte) named pipes sockets (z.b. TCP/IP sockets, UNIX domain sockets) symbolic links (Verweise) 10

11 Mounten von Filesystemen Zusammenfassen mehrerer File-Systeme in einer Directorystruktur Eingebundenes Filesystem ist entweder: lokal verfügbar (z.b. untersch. Partition oder Festplatte, Wechseldatenträger), verfügbar via Netzwerk (z.b. über NFS), oder befindet sich selbst in einem File (loop device für ISO-Images) Vorteil: untersch. Filesysteme gleichzeitig verwendbar 11

12 Virtuelles Filesystem (VFS) > 15 physikalische Filesysteme unter Linux in Verwendung Kompatibilität zu anderen Systemen (z.b. NTFS, FAT) Sicherheit, Zuverlässigkeit der Daten (z.b. Ext3, ReiserFS) Performance (z.b. XFS) Einführung einer zusätzlichen Abstraktionsebene einheitliche Schnittstelle (super block, i-node, directories, files) transparentes Mounten verschiedener physikalischer Filesysteme in eine Directory-Struktur 12

13 Second extended filesystem Ext2 (1) Lange Zeit das Standard-Filesystem unter Linux Organisation des Filesystems in Ext2-Superblock beschreibt Größe und Struktur des Filesystems (zentral für Ext2 repliziert) beinhaltet Versionsinformation (magic number, revision number), Anzahl der freien Blöcke sowie i-nodes, Blockgröße und Anzahl der Blöcke insgesamt Ext2-i-node ähnliche Information wie in VFS i-nodes (Zugriffsrechte, Größe, Besitzer, ) zusätzlich Zeiger auf Datenblöcke der Files (direkte Zeiger, indirekte Zeiger und zweifach indirekte Zeiger Performanceeinbußen) 13

14 Second extended filesystem Ext2 (2) Organisation des Filesystems (Forts.) Ext2-Zylindergruppenblock Informationen über die Anzahl und Belegung der Blöcke in der Zylindergruppe Directory Struktur Directory speichert nur Name und zugeordneten i-node des Files (i-node Nummer des Files, Länge des Filenamens, Länge des gesamten Directoryeintrages, Filename) zum Löschen eines Files wird i-node Nummer auf 0 gesetzt und Länge des gelöschten Eintrags zum vorherigen Eintrag addiert 14

15 Allokation von Plattenblöcken in Ext2 (1) Performance von Filesystem hängt (grob) von zwei Faktoren ab Organisation der i-nodes (B-tree, B*-tree, etc.) Allokation freier Speicherblöcke zu Files Exkurs Aufbau und Organisation einer Festplatte Physikalisch mehrere drehbar gelagerte Scheiben (platters) mehrere bewegbare Lese/Schreibköpfe (heads) Antrieb und Steuerungselektronik für platters und heads Logisch magnetisierte Spuren als konzentrische Kreise auf den Scheiben Übereinanderliegende Spuren bilden Zylinder, benachbarte Zylinder bilden Zylindergruppe 15

16 Allokation von Plattenblöcken in Ext2 (2) Ziel der Allokationsheuristik: Zugriffszeit auf Files zu minimieren Globale Strategie (zur Bestimmung der ungefähren Speicherposition für Files und Directories) i-nodes aller Files in Zylindergruppe des zugehörigen Directories Datenblöcke eines Files in selbe Zylindergruppe wie i-node des Files (große Dateien über mehrere Zylindergruppen verteilt, um Auffüllen zu verhindern) Daten ohne logischen Zusammenhang möglichst gleichmäßig verteilt neue Directories in Zylindergruppe mit möglichst vielen freien i-nodes so wie möglichst wenig bestehenden Directory-Einträgen Interleaving von aufeinander folgenden Datenblöcken eines Files (Interleaving Faktor von Interrupt Service Time bestimmt) 16

17 Allokation von Plattenblöcken in Ext2 (3) Lokale Strategie (zur Bestimmung der tatsächlichen Speicherposition) angeforderte Blöcke der globale Strategie können tlw. bereits belegt sein (ansonsten wären die Algorithmen zu zeitaufwendig) lokale Algorithmen führen Suche nach freien Blöcken in der Umgebung durch bevorzugt im gleichen Zylinder bzw. Zylindergruppe falls nicht erfolgreich, wird gesamte Platte durchsucht sehr zeitaufwendig Filesystem nicht mehr als z.b. 90% befüllen weitere Blöcke nur mehr von Prozess mit superuser Berechtigung anforderbar 17

18 Journaling Filesysteme Journal beinhaltet sämtliche momentan bearbeiteten Dateien im Falle eins Systemabsturzes, müssen nur diese Dateien auf Konsistenz überprüft werden transaktionsbasiert: Datei behält solange ihre Gültigkeit, bis Bearbeitung vollständig abgeschlossen ist ReiserFS (Vers. 3): Datenorganisation mit B+-Bäumen effektive Organisation von vielen, kleinen Dateien Ext3: Erweiterung von Ext2 um Journal (Kompatibilität bleibt bestehen) einfache (gefahrlose) Konvertierung von Ext2 auf Ext3 Filesystem XFS, JFS, 18

19 Aufgaben des Kernels Prozessverwaltung Interprozesskommunikation Speicherverwaltung Filesystemverwaltung Peripherieverwaltung Networking 19

20 UNIX Peripherie Überblick UNIX I/O Struktur Device Driver block device driver character device driver Line Disciplines für character devices Scatter gather I/O 20

21 Struktur des UNIX I/O Systems Zugriff auf Geräte in UNIX über device driver block device driver (Zugriff über Filesystem oder direkt) character device driver (direkter Zugriff oder line disciplines) network device driver (Zugriff über Netzwerkprotokollstack) 21

22 Device Driver (1) Major Device Number spezifiziert den Typ des Devices und damit den zu verwendenden device driver möglich für verschiedene Devicetypen den gleichen device driver zu verwenden (/dev/mem und /dev/kmem) Minor Device Number spezifiziert genau das zu verwendende Gerät möglich nur Teile eines Geräts durch die minor device number anzusprechen (z.b. Partitionen einer Festplatte) brw-rw---- crw-rw root disk 8, 1 May 8 05:20 sda1 1 root uucp 4, 64 May 8 05:20 ttys0 22

23 Device Driver (2) Device driver sind typischerweise zweigeteilt: Top Half u. Bottom Half Top Half läuft im Kontext des aufrufenden Prozesses wird durch System Call aktiviert und initiiert Datentransfer vom/zum Gerät bei Lese- oder synchroner Schreiboperation wird auf Beendigung des Transfers gewartet (sleep_on()) Bottom Half läuft asynchron zum Benutzerprozess in einem eigenen Kontext wird durch Interrupt vom Gerät nach Beendigung des Datentransfers aufgerufen nach Abarbeitung des Interrupts wird Top Half geweckt (wake_up()) 23

24 Device Driver (3) Kommunikation zwischen Top Half und Bottom Half über gemeinsame Datenstrukturen Ausnahme der Strukturierung: software devices besitzen keine Bottom Half /dev/mem bzw. /dev/kmem (physikalischer Hauptspeicher) /dev/null (Datensenke) /dev/zero (Datenquelle) 24

25 Lesezugriff auf Device 25

26 Lesezugriff auf Device (verzögert) 26

27 Schreibzugriff auf Device (asynchron) 27

28 Block Device Driver Wahlweiser Zugriff auf Blöcke fixer Größe (über Block Buffer Cache) Bsp.: Festplatte, Magnetbänder, etc. Wichtigste Routinen eines Block Device Drivers open(): Vorbereitung auf spätere Zugriffe (Init. der Datenstrukturen) release(): Gerät wird momentan von keinem Prozess genutzt strategy(): Festlegung der Ordnung der Lese-/Schreibzugriffe ioctl(): Einstellen Device-spezifischer Parameter (z.b. Position des Magnetbandes) Minimierung der Suchzeit von Blöcken durch Zugriffsstrategie Elevator Algorithmus: Aufzugprinzip C-SCAN Algorithmus: Requests nur in festgelegter Richtung abgehandelt 28

29 Elevator & C-SCAN Algorithmus C-SCAN: keine Benachteiligung von inneren und äußeren Blöcken. 29

30 Character Device Driver (1) Raw Devices wahlfreier Zugriff auf Peripheriegeräte (ohne Block Buffer Cache) keine Organisation in fixe Blockgrößen notwendig oftmals auch raw Zugriff über Block Devices (z.b. Harddisk) Character Oriented Devices zeichen- bzw. zeilenorientierter Zugriff z.b. Terminal Devices, Drucker, etc. Wichtigste Routinen eines Character Device Drivers (außer open(), release() und ioctl()) read(), write(): einzeln oder blockweises Lesen/Schreiben von Daten select(): Überprüfung ob Daten zum Lesen bzw. Platz zum Schreiben vorhanden ist (für character oriented devices) 30

31 Character Device Driver (2) Line Disciplines Implementierung von generellen Routinen, die weder vom Device Driver noch vom verwendeten Programm abhängig sind (zw. SysCall und Treiber) z.b. Behandlung von erase und kill Zeichen bei Terminals einstellen der Line Discipline mittels ioctl() Kommunikation über uio-struktur ermöglicht scatter gather I/O Lesen/Schreiben von Daten von/in unterschiedliche Adressbereiche mit einer atomic action 31

32 Aufgaben des Kernels Prozessverwaltung Interprozesskommunikation Speicherverwaltung Filesystemverwaltung Peripherieverwaltung Networking 32

33 Networking Überblick Internet Protokolle (kurzer Überblick) IP (RFC 791) UDP (RFC 768) TCP (RFC 793) UNIX Data Streams Netzwerk-Filesysteme NFS RFS Packet Filter 33

34 Internet Protokolle Protokolle zur Datenübertragung über paket-orientierte Netzwerke RFCs unter Aufsicht der DARPA des US DoD IP (Internet Protocol) ungesichertes Datagram Service baut auf untergelagerten Netzwerkprotokollen (Ethernet, Token Ring, etc.) auf aufbauend auf IP UDP: ungesichertes Datagram Service TCP: verbindungs-orientiertes, zuverlässiges Stream Service 34

35 Internet Protocol (1) Abstraktion über physikalische Struktur des unterliegenden Netzwerkes Übertragung von einzelnen Paketen (Datagrams) von Rechner A zu Rechner B jedoch keine gesicherte Übertragung, d.h. keine Acknowledgements, keine Fehlerkontrolle und Wiederholung im Fehlerfall, keine Flusskontrolle Hauptaufgaben von IP Routing: Weiterleiten von (logisch adressierten) Paketen über Gateways (router) in Richtung ihres Zielnetzwerks Fragmentierung: Anpassung der Paketgröße an das unterlagerte Netzwerk (z.b. max Bytes bei Ethernet) 35

36 Internet Protocol (2) IPv4 Header IHL: Länge des Headers Typ des Services: QoS Parameter (z.b. durch Prioritisierung) Identifikation, Fragment Flags und Offset: Parameter für Fragmentierung Lebenszeit: Mischung aus hop count und echter Zeit (wird bei jeder Verarbeitung des Pakets verändert) Protokoll: Indikator für das nächst höhere Protokoll Zieladresse: für Routing Optionen: Zeitstempel, aufgezeichnete Route, fixe Route 36

37 User Datagram Protocol Einfaches Datagram Protokoll ungesichert verbindungslos paket-orientiert Aufbauend auf IP zusätzliche Services: Ports für Multiplexing und Demultiplexing Prüfsumme über Daten 37

38 Transmission Control Protocol (1) Verbindungs-orientiertes Protokoll zur gesicherten Übertragung von Datenströmen Aufbauend auf datagram service (z.b. IP) zusätzliche Services Fragmentierung (Sender) und Zusammensetzen (Empfänger) von Datastreams in/aus Pakete(n) Fehlertoleranz (beschädigte, verlorene, duplizierte oder umgeordnete Pakte) mittels positive acknowledgement or retry (PAR) Protokoll Flusskontrolle mittels back pressure (sliding window) Zugriff mehrerer Prozesse auf das Netzwerk mittels Ports (entsprechen Sockets am Rechner) Aufbau und Verwaltung von Verbindungen zwischen Sockets mittels 3-Wege Handshake mit sequence number 38

39 Transmission Control Protocol (2) TCP Header Sequence Number: zur Erkennung von Retransmissions ACK number: sequence number des nächsten erwarteten Pakets, dient zur Implementierung des Sliding Window Protokolls Window: Anzahl der noch akzeptierten Bytes zur Flusskontrolle Prüfsumme: zur Erkennung von Übertragungsfehlern (über Header und Daten berechnet) Dringlichkeitsinformation: sogenannte out-of-band Daten realisieren einen logischen Kanal, um dringende Daten zwischendurch zu übertragen 39

40 UNIX Data Streams (1) Wichtiger Mechanismus um konzeptionelle Schwäche von Unix- Systemen bei Netzwerk-Kommunikation auszubessern Character Devices behandeln Datenstrom zeichenweise für Netzwerk- Protokolle ist Nachrichten-basierte Behandlung oft notwendig Mehrfachimplementierung eines selben Konzepts wird durch Line Disciplines umgangen diese sind jedoch nicht mehrfach hintereinander anwendbar (Netzwerkprotokolle bauen oft auf einem ganzen Stack von Protokollen auf) Streams scheinen im Filesystem als Character Special File auf Stream ist bidirektionale Verbindung zwischen einem Prozess und einem Treiber 40

41 UNIX Data Streams (2) Streams bestehen aus mehreren Modulen (ioctl-push, ioctl-pop) Stream Head und Device Driver sind immer vorhanden jedes Modul besitzt eine Eingabeund eine Ausgabe-Queue Queues behandeln Daten Nachrichtenbasiert und unterstützen Prioritäten Module unterstützen nach außen vier Prozeduren open() und close() put(): Übergabe einer Nachricht an ein Modul service(): Bearbeitung der Nachrichten in der lokalen Queue des Moduls 41

42 UNIX Data Streams (3) Multiplexen von Streams 42

43 Netzwerk Filesysteme Motivation: Aufbau von heterogenen Systemen über Netzwerkverbindungen (z.b. Zusammenschluss von mehreren Rechnern (mit unterschiedlichen Betriebssystemen) über das Netzwerk Zugriff auf (gemeinsame) Files über das Netzwerk Ziel: Homogenes Gesamtsystem Server stellen Files zur Verfügung (Export) Clients binden Files in ihre lokale Directory-Struktur ein (Mount) Wichtiger Aspekt Security z.b. Zugriffsrechte: Abbildung zwischen Benutzern auf dem Server und auf dem Client 43

44 Network File System (NFS) Sun Client / Server Architektur ursprünglich auf UDP/IP aufbauend (seit NFS 4 auf TCP/IP) Datenaustausch über RPC/XDR (external data representation) ursprünglich stateless Server (d.h. Server speichert keine Information über clients), dadurch + Idempotenz der Clientanforderungen + einfaches Recovery keine special files (Devices, Streams, Terminals) kein ioctl (würde Zustand erzeugen) (seit NFS 4 wird Konzept des stateful Servers unterstützt) 1 1 Abbildung zwischen Benutzern auf Client und Server 44

45 Remote File System (RFS) AT&T Client / Server Architektur auf TCP/IP aufbauend Server mit Zustandsinformation (stateful server) + special Files möglich komplexeres Recovery Beliebige Verzeichnisbäume (auch Teilbäume) können exportiert werden (directory-oriented export) Multi-hop Export möglich Beliebiges Mapping von Benutzern auf Server und Client Namensgebung symbolisch über DNS 45

46 Packet Filter (1) Direkter Zugriff auf Netzwerkhardware (über network device driver) Verschiedene Realisierungen Linux Berkeley Packet Filter (PCAP Library) DEC: ULTRIX Packet Filter SunOS: STREAMS NIT Anwendung: Realisierung von Filterprogrammen Implementierung eigener Netzwerkprotokolle Aufteilung der empfangenen Pakete zwischen einzelnen Programmen selektives Lesen von Datenpaketen 46

47 Packet Filter (2) Zugriff auf Packet Filter via Character Special Files (z.b.: /dev/bpf??) gleiche major device number unterschiedliche minor device number Packet Filter in Linux nicht Teil des Kernels (laufen im User-Mode ab) Pro offenem Packet Filter Special File ein Filterprogramm Zuordnung von Prioritäten zu Filterprogrammen Festlegung der Abarbeitungsreihenfolge Steigerung der Effizienz (Filterprogramme mit höherer Wahrscheinlichkeit eines match zuerst abarbeiten lassen) Von Standardprotokoll verarbeitete Pakete gelten als konsumiert und werden nicht mehr an Packet Filter weitergeleitet 47

48 Packet Filter (3) Benutzung von Berkeley Packet Filter öffnen eines Character Special Files (pfopen) zuordnen eines Netzwerkinterfaces (ioctl) zuordnen eines Filterprogrammes (ioctl) Empfang von Paketen mittels read mit/ohne Timeout select bei mehreren Kanälen Versand von Paketen mittels write 48

49 Danke für Ihre Aufmerksamkeit! 49