Betriebssysteme. Datenmanagement

Transkript

1 erstellt durch: Name: Telefon: Fax: / / mailto: Karl.Wohlrab@fhvr-aiv.de Der Inhalt dieses Dokumentes darf ohne vorherige schriftliche Erlaubnis des Autors nicht (ganz oder teilweise) reproduziert, benutzt oder veröffentlicht werden. Das Copyright gilt für alle Formen der Speicherung und Reproduktion, in denen die vorliegenden Informationen eingeflossen sind, einschließlich und zwar ohne Begrenzung Magnetspeicher, Computer ausdrucke und visuelle Anzeigen. Anmerkungen Bei dem vorliegenden Scriptum handelt es sich um ein Rohmanuskript im Entwurfsstadium. Das Script wird begleitend zur Lehrveranstaltung fortgeschrieben und überarbeitet. Es erhebt keinen Anspruch auf Vollständigkeit und Korrektheit. Inhaltliche Fehler oder Ungenauigkeiten können ebenso wenig ausgeschlossen werden wie Rechtschreibfehler. BS_.odt Seite 1 von 54

2 Inhaltsverzeichnis 1. Allgemeine Einführung in das Allgemeines Datenträgerverwaltung Disketten Aufbau einer Diskette Charakteristik von Disketten Leistungsmerkmale von Disketten Fest- und Wechselplatten Charakteristik von Festplatten: Prinzipieller Aufbau von Festplatten Bandspeicher Charakteristik von Bandspeichern Dateien Allgemeines Anforderungen an die Verwaltung von Daten Benennung von Dateien Dateistrukturen Dateitypen Dateisystemimplementierungen (geplant) Verzeichnisse Verzeichnissysteme mit einer Ebene Verzeichnissysteme mit zwei Ebenen Hierarchische Verzeichnissysteme Das LINUX-Verzeichnissystem Pfadnamen Operationen auf Verzeichnissen Regeln für die Benennung von Dateien Byte-Stream Record-Stream (SAM- und ISAM-Dateien) Baumstruktur Reguläre Dateien Aufbau einer Datei unter UNIX absolute Pfadnamen relative Pfadnamen Die Verzeichnisse. und BS_.odt Seite 2 von 54

3 4. Realisierungsprinzipien Allgemeines Implementierung von Dateisystemen Layout eines Dateisystems Typischer Aufbau eines Dateisystems Realisierung von Dateien Datei als Menge von zusammenhängenden Blöcken...44 Datei als verkettete Liste von Blöcken...47 Datei als verkettete Liste in einer Hauptspeichertabelle (FAT)...48 NTFS...49 I-Nodes mit LINUX Backup und Recovery mit WINDOWS Backup und Recovery Abbildungsverzeichnis...54 BS_.odt Seite 3 von 54

4 1. Allgemeine Einführung in das 1.1 Allgemeines Literaturhinweise: [Tann02] Kap. 6, Seite 407 ff Die elektronische Datenverarbeitung dient (wie der Name schon andeutet) zur Verarbeitung von Daten / Informationen auf elektronischen Wege. Selbstverständlich ist damit auch die Anforderung zur Aufbewahrung dieser Daten mit verbunden z.b. als Eingangsgangsdaten, Zwischen- und Endergebnisse und Ausgabedaten. Zunächst sollte vielleicht geklärt werden was Daten überhaupt sind: Abbildung 1: Was sind Daten? Hieraus ergeben sich verschiedene Anforderungen an die Verwaltung von Daten: BS_.odt Seite 4 von 54

5 Abbildung 2: Anforderungen an die Verwaltung von Daten BS_.odt Seite 5 von 54

6 1.2 Datenträgerverwaltung Aufgrund der unterschiedlichen Anforderungen an die Datenspeicherung sind natürlich auch die unterschiedlichen charakteristischen Merkmale der unterschiedlichen Datenträger zu beachten: Disketten Abbildung 3: gängige Diskettenformate BS_.odt Seite 6 von 54

7 Aufbau einer Diskette Abbildung 4: Aufbau einer Diskette Charakteristik von Disketten Auswechselbarer Datenträger (auch während des Betriebs des Rechners) Begrenzte Kapazität (360/720 kb bzw. 720 kb/1,44 MB) 1 oder 2 beschreibbare magnetisierbare Oberflächen 40 oder 80 Spuren je Oberfläche 15/18 Sektoren je Spur Interleave-Faktor zur Beschleunigung von Zugriffen auf den Datenträger meist Zusammenfassung von 2 Sektoren zu einem Cluster Disketten sind nur während des Schreib-/Lese-Vorgangs in Betrieb BS_.odt Seite 7 von 54

8 Leistungsmerkmale von Disketten Abbildung 5: Speicherkapazität von Disketten BS_.odt Seite 8 von 54

9 1.2.2 Fest- und Wechselplatten Abbildung 6: Festplatten Charakteristik von Festplatten: Im Normalfall nicht auswechselbarer Datenträger Große Speicherkapazität (heute üblich 40 GB 1 TB) Schneller Datenzugriff möglich Viele Scheiben mit je 2 beschreibbaren magnetisierbaren Oberflächen Mehrere hundert / tausend Spuren je Oberfläche viele Sektoren je Spur Bei Schreib-/Lesevorgängen wird meist gleich ein ganzer Zylinder in den Schreib/Lesepuffer gelesen bzw. daraus beschrieben. Festplatten sind permanent in Betrieb BS_.odt Seite 9 von 54

10 Prinzipieller Aufbau von Festplatten Abbildung 7: Aufbau einer Festplatte Abbildung 8: Schreib-/Lesekopf BS_.odt Seite 10 von 54

11 1.2.3 Bandspeicher Magnetbänder werden heutzutage nur noch als Backup-Medien für die Datensicherung verwendet. Früher dienten Magnetbänder auch als Datenspeicher für Massendaten. Abbildung 9: Magnetband als Massenspeicher Charakteristik von Bandspeichern Sehr große Speicherkapazität bei niedrigen Preis Sequentieller Datenzugriff und damit relativ langsam Feste oder variable Blockung Volume-Header zur Benennung des Bandes File-Header mit den charakteristischen Informationen zur jeweiligen Datei Daten im mehreren Blöcken Technisch bedingte Lücken zwischen den einzelnen Blöcken Fortsetzung einer Datei auf einem anderen Band möglich BS_.odt Seite 11 von 54

12 Zur Verwaltung (Speicherung, Inventarisierung, ) von Daten auf den unterschiedlichen Medien sind selbstverständlich unterschiedliche DV-Verfahren erforderlich. Die Koordination ist im Betriebssystem verwurzelt; der Zugriff auf die jeweiligen Medien wird von entsprechenden Gerätetreibern übernommen. Abbildung 10: Aufbau eines sequentiellen Bandspeichers BS_.odt Seite 12 von 54

13 2. Dateien 2.1 Allgemeines Literaturhinweise: [Tann02] Kap. 6, Seite 407 ff Das Hauptinstrument zur Speicherung von Informationen sind Dateien. Die Anforderungen an die Speicherung von Daten werden hier aus Sicht der Dateiverwaltung (siehe oben) noch einmal wiederholt 2.2 Anforderungen an die Verwaltung von Daten Abbildung 11: Anforderungen an die Verwaltung von Daten 1. Es muss möglich sein, sehr große Mengen von Informationen zu speichern. Anwendungen müssen Informationen abspeichern und wieder finden. Der Zugriff auf die gespeicherten Daten muss möglichst schell erfolgen; ebenso der Vorgang des Abspeicherns. Der Datenträger muss möglichst preiswert sein. BS_.odt Seite 13 von 54

14 2. Die Informationen müssen die Terminierung der Prozesse, die diese verwenden, überleben 3- Die Datenspeicherung muss dauerhaft sein (evtl. mehrere Jahre oder gar Jahrzehnte) Die langfristige Speicherung der Daten im Adressraum des Programmes ist ausgeschlossen Ältere Daten müssen auch mit neueren Systemen noch einwandfrei gelesen werden können eine höchst problematische Anforderung Es muss für mehrere Prozesse möglich sein, gleichzeitig auf die Informationen zugreifen zu können ohne einander zu behindern Informationen werden häufig von mehreren Anwendungen (genauer Prozessen) gleichzeitig benötigt. Das Betriebssystem muss die Datenzugriffe koordinieren und bei Bedarf auch einem Prozess das Recht zur Änderung der Daten entziehen. Lese- und Schreibrechte sind hier unterschiedlich zu behandeln. Der Zugriff darf nur für entsprechend autorisierte Anwender (Prozesse) freigegeben werden. Diese Anforderungen können mit folgenden Maßnahmen gelöst werden: Informationen werden auf Medien für die langfristige Datenhaltung (LFD) gespeichert. z.b.: Plattenspeicher, Bandspeicher, Lochkarte, Diskette, Trommelspeicher, Verwaltung unterschiedlicher Informationen in organisatorisch und inhaltlich zusammengehörenden Einheiten den Dateien oder Files Dateien müssen zumindest für folgende Aufgaben verfügbar sein: 1. Programme (eigentlich Prozesse) können Dateien lesen und ggf. neu beschreiben 2. Die in Dateien gespeicherten Informationen müssen persistent sein, d.h. nicht von der Erzeugung und Terminierung von Prozessen abhängig sein. 3. Eine Datei darf nur verschwinden, wenn ihr Eigentümer sie explizit entfernt. BS_.odt Seite 14 von 54

15 Die Verwaltung der Dateien erfolgt durch das Betriebssystem: Abbildung 12: Dateiverwaltung durch das Betriebssystem Aus Benutzersicht sind dabei vor allem folgende Fragen von Interesse: Wie werden Dateien gegenüber dem Benutzer dargestellt? Was macht eine Datei aus? Wie werden Dateien benannt? Wie werden Dateien geschützt? Welche Operationen sind für Dateien definiert? Aus Betriebssystemsicht sind dagegen mehr folgende Fragen besonders wichtig: Wie wird der freie und der belegte Speicherplatz verwaltet? Sektoren und Blockgrößen? Sicherheits- und Schutzmechanismen BS_.odt Seite 15 von 54

16 2.3 Benennung von Dateien Literaturhinweise: [Tann02] Kap. 6.1, Seite 408 ff Aus Benutzersicht genügt die Angabe des Dateinamens für den Zugriff auf die Datei. Systemtechnische Detailinformationen (wo und wie die Daten der Datei gespeichert sind) bleiben dem Benutzer dabei verborgen. Aus diesen Gründen beginnen wir die Untersuchung des Dateisystems ebenfalls mit den Dateinamen. Wenn ein Prozess eine Datei erzeugt gibt er ihr einen Namen Terminiert der Prozess, so bleibt die Datei bestehen Ein (beliebiger) anderer Prozess kann mit Hilfe des Dateinamens auf die Datei zugreifen Abbildung 13: Der Dateibegriff Die Regeln für die Benennung von Dateien variieren zwischen den unterschiedlichen n: Länge des Dateinamens Groß- und/oder Kleinschreibung Sonderzeichen Ziffern Einteilige / mehrteilige Dateinamen BS_.odt Seite 16 von 54

17 Abbildung 14: Dateinamen unter MS-DOS Abbildung 15: Einige wichtige Extensions BS_.odt Seite 17 von 54

18 2.3.1 Regeln für die Benennung von Dateien Literaturhinweise: [Tann02] Kap. 6.1, Seite 408 ff 1. alle aktuellen akzeptieren 1 bis 8-stellige Strings als Dateiname 2. Zahlen und Sonderzeichen sind häufig erlaubt; es gibt aber nahezu überall Einschränkungen oder Besonderheiten zu beachten: Beispiele für Einschränkungen: Name muss mit einem Buchstaben beginnen (keine Ziffern; keine Sonderzeichen Nur bestimmte Sonderzeichen erlaubt Besondere Bedeutung von '*', '?', '.' 3. Groß- und Kleinschreibung UNIX / LINUX ja MS-DOS / WINDOWS nein 4. Maximale Namenslänge Beispiele für typische Werte: 8 ( + 3) Zeichen 255 Zeichen 5. häufig geteilte Namen <name>. <extension> 6. Namenserweiterung (Extension) MS-DOS Verweis auf Typ der Datei und das zugehörige Bearbeitungsprogramm UNIX / LINUX Erweiterung ohne technische Bedeutung Wird nur als Memo für den Benutzer verwendet (optional) BS_.odt Seite 18 von 54

19 2.4 Dateistrukturen Literaturhinweise: [Tann02] Kap , Seite 410 ff Gebräuchliche Dateistrukturen sind: a) Byte-Sequenz (Bytestream) b) Record-Sequenz c) Baum Abbildung 16: Dateistruktur: sequentielle Dateien Byte-Stream Die wichtigsten Merkmale von Byte-Stream-Dateien sind: Das Betriebssystem hat keine Information über der Dateiinhalt Die Bedeutung liegt alleine im Benutzerprogramm und der Interpretation der Daten im Benutzerprogramm Wird unter UNIX und WINDOWS verwendet. BS_.odt Seite 19 von 54

20 Damit ist für die Arbeit mit Dateien ein Maximum an Flexibilität gewährleitset. Die Benutzerprogramme können "praktisch Alles" komfortabel abspeichern. Das Betriebssystem unterstützt das Anwendungsprogramm nicht bei der Datenverwaltung, es behindert aber im Gegenzug auch nicht Record-Stream (SAM- und ISAM-Dateien) Die wichtigsten Merkmale von Record-Stream-Dateien sind: Die Datei ist eine Sequenz von Sätzen (Records) fester Länge Records haben ggf. eine interne Struktur (Datenfelder) Jede Leseoperation gibt genau einen record zurück Jede Schreiboperation überschreibt oder ergänzt genau einen Record Historischen Größen für Records sind: 80 Bytes 132 Bytes ehem. Lochkarte Zeilendrucker (z.b.: Kettendrucker, Trommeldrucker,...) Die Strukturierung der Datensätze hat für den praktischen Einsatz folgende Konsequenzen: einfache Schreib-/Leseroutinen da feste Satzstruktur ggf. Platzverschwendung falls Records nur gering ausgelastet mit der Einführung von Bildschirmterminals und der Eingabe von Daten variabler Länge, verloren Dateien mit fester Satzlänge ihre Bedeutung. Record-Stream-Dateien sind vom Grundkonzept her nur sequentiell zu bearbeiten, man spricht deshalb auch von sequentiellen Dateien. Wenn man den 325. Satz lesen wollte, musste man zuerst die Sätze 1 bis 324 lesen, um an den gewünschten Satz zu gelangen. Eine bestehende Datei konnte nur am Ende erweitert werden, in dem weitere Sätze angefügt wurden das Einfügen von Sätzen war nicht bzw. nur mit hohen Aufwand (Umkopieren der Datei) möglich. Ebenso war es sehr aufwändig, eine sequentielle Datei zu sortieren. Die Zugriffsmethode für sequentielle Dateien wird als SAM (Sequential Access Method) bezeichnet. BS_.odt Seite 20 von 54

21 Zur Verbesserung der Zugriffsmöglichkeiten und der Zugriffsgeschwindigkeit wurde die Zugriffsmethode ISAM (Index Sequential Access Method) eingeführt. In anderen Systemen wird auch der Begriff VSAM (= Virtual SAM) verwendet. Folgendes Grundprinzip steckt dahinter: Nachdem jeder Record gleich lang ist, kann man berechnen im wievielten Block der Datei ein bestimmter Record gespeichert ist. Wird ein bestimmter Record benötigt (hierzu muss man natürlich die Nummer des Blocks wissen), wird der Block in dem der Record steht direkt gelesen; innerhalb des Blocks wird dann sequentiell nach dem gewünschten Record gesucht. Zur leichteren Verwaltung der Satznummern wird eine zusätzliche Index-Datei geführt (häufig *.idx als Extension) in der eine Zuordnung des Schlüsselbegriffs zur Satznummer verwaltet wird. In der Indexdatei steht also der Schlüsselbegriff (das Ordnungskriterium) des jeweiligen Datensatzes, sowie die Nummer des Datensatzes (und als zusätzlicher Komfort noch die Nummer des betreffenden Blockes). Die IndexDatei ist wesentlich kleiner als die zugehörige Datendatei evtl, kann sie zur Performanceverbesserung sogar ganz im Arbeitsspeicher gehalten werden. Abbildung 17: Dateistruktur: indexsequentielle Dateien BS_.odt Seite 21 von 54

22 Ein Vorteil von ISAM-Dateien ist, dass es bei Sortieroperationen meist ausreicht, wenn die Index-Datei sortiert wird Falls Sätze eingefügt werden sollen, werden diese physikalisch am Ende der Datei angefügt; ihr Ordnungsbegriff wird aber in der Indexdatei an der entsprechenden Stelle einsortiert Baumstruktur Die wichtigsten Merkmale von Baum-Dateien sind: Die Datei besteht aus einem Baum von Records Die Satzlänge ist nicht zwingend gleich; i.d.r. unterschiedlich zur Handhabung enthält jeder Satz am Satzanfang ein Satzlängenfeld (SLF) Jeder Record hat an einer festen definerten Stelle (i.d.r. unmittelbar nach den SLF) ein Schlüsselfeld zur Identifizierung des Records Der Baum ist nach diesem Schlüsselfeld sortiert. Abbildung 18: Dateistruktur: Baumstruktur Konsequenzen für den praktischen Einsatz: Schnelle Suche (und Zugriff nach bestimmten Schlüsseln ist möglich Entfall der Indexdatei (sofern der Schlüssel das einzige Suchkriterium ist) Verwaltung der Datei durch das Betriebssystem BS_.odt Seite 22 von 54

23 Entlastung des Benutzerprogrammes Die Bearbeitung ist möglich, ohne genau zu wissen, wo der Record in der Datei abgelegt ist. Über die Platzierung neuer Einträge entscheidet das Betriebssystem und nicht der Benutzer. Anmerkung: Baumartige Dateien kommen überwiegend in der kommerziellen Groß-DV (also auf Großrechnern) vor. UNIX/LINUX bzw. DOS/WINDOWS unterstützen keine Baumartigen Dateien. Dies schließt natürlich nicht aus, dass evtl. Anwendungsprogramme (z.b.: Datenbankanwendungen) mit einer eigenen (internen) Datenorganisation Baumstrukturen verwenden; aus Betriebssystemsicht werden die betreffenden Dateien jedoch als Bytestream-Dateien behandelt. BS_.odt Seite 23 von 54

24 2.5 Dateitypen Literaturhinweise: [Tann02] Kap , Seite 411 ff unterstützen in der Regel mehrere Dateitypen. UNIX und WINDOWS unterstützen z.b.: Reguläre Dateien und Verzeichnisse UNIX verwendet auch noch spezielle Zeichen und Blockdateien Reguläre Dateien enthalten Benutzerinformationen Sie entsprechen dem allgemein geläufigen Dateibegriff. Verzeichnisse sind Systemdateien zur Verwaltung des Dateisystems Details siehe unten Spezielle Zeichendateien dienen der Ein-/ Ausgabe (z.b.: UNIX-Device-Files in /dev) Sie modellieren serielle E/A-Geräte (Terminals, Drucker, Netzwerke, ) Spezielle Blockdateien dienen der Modellierung der I/O auf blockorientierte Geräte (Disketten, Festplatten, ) Reguläre Dateien Reguläre Dateien sind wie folgt zu charakterisieren: Im Allgemeinen ASCII oder Binärdateien ASCII-Dateien bestehen aus Textzeilen Jede Zeile endet mit dem Zeilenendezeichen (RETURN; CR) und/oder Zeilenvorschub (LF) Zeilen müssen nicht zwingend die gleiche Länge haben ASCII-Dateien können so wie angezeigt auch gedruckt werden ASCII-Dateien können mit einem einfachen Texteditor bearbeitet werden Relativ einfache Interprozesskommunikation mit Hilfe von ASCII-Dateien Binärdateien können nicht einfach gedruckt werden; hier ist zumindest ein geeigneter Editor (mit Druckfunktionalität) erforderlich (Typisches Beispiel: WORD-Dateien) Binärdateien besitzen meist eine innere Struktur, die nur dem Bearbeitungsprogramm bekannt ist. BS_.odt Seite 24 von 54

25 2.5.2 Aufbau einer Datei unter UNIX Literaturhinweise: [Tann02] Kap , Seite 411 ff Abbildung 19: Aufbau einer Datei unter UNIX / LINUX Magic Number Identifizierung der Datei als ausführbare Datei Als Vorbeugung, damit nicht versehentlich eine Datei ausgeführt wird, die gar nicht für die Ausführung vorgesehen ist Textgrösse Data-Grösse BSS-Grösse Symboltabellengrösse Größenangaben für die verschiedenen Abschnitte der Datei Einstiegspunkt Anfangsadresse des Programms An dieser Adresse beginnt die Ausführung unused Ggf. ungenutzter Bereich Flags Verschiedene Flag-Bits BS_.odt Seite 25 von 54

26 Text Er ablauffähige Programmcode (übersetzt und gebunden) Wird in den Arbeitsspeicher geladen Daten Daten zur Bearbeitung durch das Programm Wird in den Arbeitsspeicher geladen Relocation-Bits Information zur Anordnung von Text und Daten im Arbeitsspeicher Dient der Umsetzung der programmlokalen Adressen in die absoluten Adressen der Speicherzellen im Arbeitsspeicher Symboltabelle Tabelle aller im Programm verwendeten Symbole (Konstanten, Variablen, ) und der zur Laufzeit zugewiesenen Speicherstellen als Hilfsmittel bei eventuell erforderlicher Fehlersuche (Debugging) Eine Archivdatei ist z.b. eine Bibliotheksdatei (z.b.: Modulbibliothek zum linken ablauffähiger Programme), in der mehrere / viele Module in der oben beschriebenen Struktur verwaltet werden. 2.6 Dateisystemimplementierungen (geplant) Stichpunktsamlung: Implementierung von Dateien und Verzeichnissen Common-Bereiche und privater Speicher Plattenplatzmanagement Dateisystemperformance BS_.odt Seite 26 von 54

27 3. Verzeichnisse Literaturhinweise: [Tann02] Kap. 6.2, Seite 421 ff Verzeichnisse dienen der Verwaltung mehrerer (vieler) Dateien. Folgende Begriffe werden synonym für Verzeichnisse verwendet: Ordner, Directory, Folder Verzeichnisse sind in vielen Fällen selbst wieder Dateien Man unterscheidet heute: Verzeichnissysteme mit einer Ebene Verzeichnissysteme mit zwei Ebenen Hierarchische Verzeichnissysteme 3.1 Verzeichnissysteme mit einer Ebene Literaturhinweise: [Tann02] Kap , Seite 421 ff Verzeichnissysteme mit nur einer Ebene sind die einfachste Form eines Verzeichnissystems. Man spricht auch vom Wurzelverzeichnis oder root-directory. Das Wurzelverzeichnis beinhaltet alle Dateien. Abbildung 20: Verzeichnissystem mit einer Ebene BS_.odt Seite 27 von 54

28 Anwendungsbeispiele für Verzeichnissysteme mit einer Ebene: CDC6000 (erster Supercomputer) Frühe PCs Vorteile: Einfache Suche es gibt nur einen Ablageort an dem man nach einer Datei suchen muss Nachteile: Eindeutige Namensvergabe bei mehreren Anwendern häufig problematisch BS_.odt Seite 28 von 54

29 3.2 Verzeichnissysteme mit zwei Ebenen Literaturhinweise: [Tann02] Kap , Seite 422 ff Zur Vermeidung von Namenskonflikten zwischen Dateien verschiedener Benutzer, bekommt jeder Benutzer sein eigenes Verzeichnis (je Benutzer genau ein Verzeichnis). Die Namensvergabe innerhalb des eigenen Verzeichnisses (=Homedirectory) ist benutzerindividuell. Abbildung 21: Verzeichnissystem mit zwei Ebenen Der Einsatz von Verzeichnissystemen mit zwei Ebenen erfordert einige grundsätzliche Annahmen: Das System erkennt den Benutzer (z.b.: anhand einer UserID) Das System kennt das Verzeichnis in den die Dateien des betreffenden Benutzers verwaltet werden. Als Konsequenz ist eine Logon -Prozedur zur Identifizierung des Benutzers erforderlich. Die einfachste Form der Implementierung gestattet den Benutzern nur den Zugriff auf die eigenen Dateien im eigenen Homedirectory. Eine gemeinsame Nutzung von Dateien durch mehre Benutzer ist hier noch nicht möglich, BS_.odt Seite 29 von 54

30 3.3 Hierarchische Verzeichnissysteme Literaturhinweise: [Tann02] Kap , Seite 423 ff Die oben beschriebene Hierarchie mit zwei Ebenen reicht nicht aus, um eine große Anzahl von Dateien zu verwalten. Deshalb wurden mehrere Verzeichnisebenen eingeführt. Damit ergibt sich auch die Möglichkeit, Dateien in logischen Gruppen zu organisieren. Die Organisationsform kann vom Benutzer individuell und flexibel bestimmt werden. Abbildung 22: Hierarchisches Verzeichnissystem mit mehreren Ebenen Damit wird jetzt eine generelle Hierarchie (~ ein Baum von Verzeichnissen) ermöglicht. Jeder Benutzer hat die Möglichkeit, beliebig viele Verzeichnisse und Unterverzeichnisse anzulegen und die Dateien nach Bedarf zu ordnen. Nahezu alle modernen Verzeichnissysteme sind als hierarchische Verzeichnissysteme organisiert. BS_.odt Seite 30 von 54

31 3.4 Das LINUX-Verzeichnissystem Abbildung 23: Das LINUX-Verzeichnissystem LINUX verwendet verschiedene Standard-Verzeichnisse. Die Dokumentation findet sich dazu in FHS (Filesystem-Hierarchy-Standard) als Teil der LINUX-Distribution bzw. im Internet. BS_.odt Seite 31 von 54

32 3.5 Pfadnamen Literaturhinweise: [Tann02] Kap , Seite 423 ff Die weiteren Betrachtungen basieren auf der Annahme; dass das Dateisystem als hierarchischer Verzeichnisbaum organisiert ist. Zum Zugriff auf eine Datei bedarf es eines "Weges" um den vollständigen Dateinamen zu spezifizieren. Hierbei sind zwei Methoden üblich: a) absolute Pfadnamen b) relative Pfadnamen absolute Pfadnamen Der absolute Pfadname spezifiziert den gesamten Pfad vom Wurzelverzeichnis beginnend bis zur Datei. Beispiel: /usr/local/bin/lla mit / usr/local/bin lla Wurzelverzeichnis Unterverzeichnisse gesuchte Datei Die Trennzeichen zwischen den Unterverzeichnissen sind Betriebssystemspezifisch. Beispiele: UNIX: /home/huber/mailbox WINDOWS: \home\huber\mailbox Multics: >home>huber>mailbox MVS / OS390 home.huber.mailbox (keine echten Verzeichnisse sondern Qualifier) BS_.odt Seite 32 von 54

33 Merke: Die Trennzeichen nennt man auch "Separator" Absolute Pfadnamen beginnen immer mit dem Wurzelverzeichnis; sie sind eindeutig Wenn das erste Zeichen des Pfadnamens der Separator ist, dann ist der Pfadname ein absoluter Pfad relative Pfadnamen Dasjenige Verzeichnis, in dem sich ein aktiver Prozess zum aktuellen Zeitpunkt befindet nennt man "aktuelles Verzeichnis" oder "Arbeitsverzeichnis". Alle Pfadnamen, die nicht mit dem Separatorzeichen beginnen werden relativ zum aktuellen Arbeitsverzeichnis angegeben die Pfadnamen nennt man "relative Pfadnamen". Beispiel: Aktuelles Verzeichnis ist /home/huber Auf die Datei /home/huber/mailbox kann mit dem einfachen Dateinamen "mailbox" zugegriffen werden. Ergänzung zum Beispiel cp /home/huber/mailbox /home/huber/mailbox.bak und cd /home/huber cp mailbox mailbox.bak sind in ihrer Wirkung identisch. BS_.odt Seite 33 von 54

34 Bei der Verwendung von absoluten und relativen Pfadnamen sind die folgenden Besonderheiten zu beachten: Benötigt ein Programm den Zugriff auf spezifische Dateien (unabhängig von aktuellen Arbeitsverzeichnis), dann sollte das Programm immer die absoluten Pfadnamen verwenden. Beispiel: Ein Rechtschreibprogramm greift immer auf die Datei /usr/lib/dictionary zu Benötigt ein Programm mehrere (evtl. viele) Dateien aus dem gleichen Verzeichnis, dann kann es evtl. sinnvoll sein, über einen Systemaufruf das Arbeitsverzeichnis entsprechend zu ändern. Die Dateien können dann über den "kurzen" Dateinamen (~relativer Pfad) angesprochen werden. Jeder Prozess hat sein eigenes Arbeitsverzeichnis. Wenn ein Prozess das Arbeitsverzeichnis ändert und später terminiert, werden davon keine anderen Prozesse berührt Die Verzeichnisse. und.. In nahezu allen hierarchischen Verzeichnissystemen gibt es die speziellen Verzeichnisse "." und ".."... = aktuelles Verzeichnis und. = übergeordnetes Verzeichnis zu " " Beispiele: Aktuelles Verzeichnis ist /usr/lib Der Zugriff auf die Datei /usr/local/bin/lla kann mit../local/bin/lla erfolgen Der Zugriff auf die Datei /home/huber/mailbox kann mit../../home/huber/mailbox erfolgen BS_.odt Seite 34 von 54

35 weitere Beispiele: Aktuelles Verzeichnis ist /usr/lib $ pwd /home/huber Die Datei soll in das aktuelle Arbeitsverzeichnis kopiert werden. Hierzu gibt es verschiedene Möglichkeiten $ cp../../usr/lib/dictionary /home/huber/dictionary $ cp /usr/lib/dictionary. $ cp /usr/lib/dictionary dictionary 3.6 Operationen auf Verzeichnissen Literaturhinweise: [Tann02] Kap , Seite 426 ff Auf Verzeichnissen sind unterschiedliche Operationen möglich. Ihre Zahl variiert zwischen den unterschiedlichen n. Hier eine Aufzählung der wichtigsten Operationen aus der UNIX/LINUX-Welt Abbildung 24: Operationen auf Verzeichnissen 1. Create Ein leeres Verzeichnis wird angelegt. lediglich die Einträge "." und ".." werden vom System automatisch angelegt BS_.odt Seite 35 von 54

36 UNIX/LINUX: MS-DOS: 2. mkdir md Delete Ein vorhandenes Verzeichnis wird gelöscht. Es dürfen unter UNIX/LINUX nur leere Verzeichisse gelöscht werden. Falls das Verzeichnis nicht leer ist, wird der Befehl zurückgewiesen lediglich die Einträge "." und ".." werden vom System automatisch angelegt UNIX/LINUX: rmdir MS-DOS: rd 3. Opendir Ein vorhandenes Verzeichnis wird zur weiteren Bearbeitung geöffnet (analog zur Bearbeitung von Dateien) und das Inhaltsverzeichnis eingelesen. 4. Closedir Ein geöffnetes Verzeichnis geschlossen und der intern verwendete Tabellenspeicher (meist im Arbeitsspeicher) wird wieder freigegeben. 5. Readdir gibt den nächsten Eintrag in einem geöffneten Verzeichnis zurück (sequentielles Lesen) 6. Rename Benennt ein vorhandenes Verzeichnis um (analog zu Dateien) UNIX/LINUX: mv MS-DOS: ren (nur innerhalb der Partition möglich) 7. Link Eine physische Datei kann mit mehreren (logischen) Dateinamen angesprochen werden, die ggf in unterschiedlichen Verzeichnissen vorkommen. Der Link erzeugt eine Verbindung von einer existierenden Datei zu dem/den spezifizierten Pfad(en) und Dateinamen. Falls durch den Link die Zahl der i-node-einträge erhöht wird, spricht man von einem Hard-Link, andernfalls handelt es sich um einen Soft-Link. 8. Unlink Entfernt den Verzeichniseintrag einer Datei. Hierbei ist zu beachten: Ist die Datei in nur einem Verzeichnis enthalten, wird sie aus dem Dateisystem entfernt (=gelöscht) Ist die Datei in mehreren Verzeichnissen vorhanden, wird nur der Eintrag in dem angegebenen Pfad entfernt und der i-node-zähler um 1 verringert. BS_.odt Seite 36 von 54

37 4. Realisierungsprinzipien 4.1 Allgemeines Die bisherigen Betrachtungen beschränkten sich auf die Benutzersicht, also um die Benennung der Verzeichnisse und Dateien und auf die hierfür zulässigen Operationen. Abbildung 25: Rolle des Betriebssystems beim Aus Systemveraltersicht sind jedoch auch detailliertere Kenntnisse über die technische Realisierung und Implementierung von Dateisystemen erforderlich, um so manche technische Restriktionen oder Möglichkeiten besser zu verstehen. Auch bei der Fehlersuche sind Kenntnisse des grundsätzlichen Aufbaus von Dateisystemen oft hilfreich. Das vorliegende Kapitel beschäftigt sich deshalb nur mit den Realisierungsgrundsätzen der gebräuchlichsten Dateisysteme. BS_.odt Seite 37 von 54

38 Abbildung 26: Zugriffe auf Dateisystem und Festplatte Die Programme und Daten der Anwender sollen auf der Festplatte gespeichert und bei Bedarf wieder gelesen werden. Hierzu bedient sich das Betriebssystem der Komponente "Dateisystem". Ein direkter Zugriff auf die Festplatte aus dem Anwendungsprogramm heraus darf grundsätzlich nicht möglich sein. BS_.odt Seite 38 von 54

39 Zur Erinnerung an dieser Stelle noch einmal kurz der schematische Aufbau einer Festplatte. Abbildung 27: Aufbau einer Festplatte Die Speicherung der Daten erfolgt in den einzelnen Sektoren (häufig allgemeiner als Blöcke bezeichnet) Bei modernen Festplatten wir nicht mehr nur der gewünschte Block gelesen, sondern es wird gleich die gesamte Spur oder gar der gesamte Zylinder in einen Lesepuffer der Platte eingelesen. Dadurch können die Zugriffszeiten (Warten auf den Sektor, Positionierungszeiten für den Schreib-Lese-Arm, ) minimiert werden. An das Betriebssystem wird lediglich der gewünschte Block weitergegeben; die andere Blöcke werden lediglich als Vorrat gehalten, falls als nächste Anforderung wieder ein Block aus dem gleichen Zylinder oder der gleichen Spur angefordert wird. Die Blöcke sind fortlaufend nummeriert; die Umsetzung der laufenden Blocknummer in Zylinder- / Spur- und Sektor-Nummer übernimmt der Plattencontroller und ist nicht Aufgabe des Betriebssystems. BS_.odt Seite 39 von 54

40 4.2 Implementierung von Dateisystemen Layout eines Dateisystems Literaturhinweise: [Tann02] Kap , Seite 428 ff Zur Aufteilung von Festplatten hat sich aus historischen Gründen ein fester Standard durchgesetzt (auch wenn unter heutigen Gesichtspunkten evtl. eine andere Lösung wünschenswert wäre). Abbildung 28: physikalische Partitionen einer Festplatte MBR Master-Boot-Record Je Festplatte gibt es grundsätzlich nur einen MBR Immer der physikalisch erste Sektor der Platte Der erste Zugriff auf die Festplatte beim Boot-Vorgang erfolgt immer auf den MBR Im MBR ist u.a. die aktive Partition definiert Das MBR-Programm (Boot-Loader) liest den ersten Block der der aktiven Partition (=Boot-Record) und führt diesen aus. BS_.odt Seite 40 von 54

41 Partitionstabelle Boot-Record Boot-Block Partitionstabelle Steht an Ende des MBR ist noch Teil des MBR Enthält Anfangs- und Endadresse jeder physikalischen Partition (Blocknummer) Größe der Partitionstabelle ist fest definiert (historisch MS-DOS: 4 Einträge) daher kann eine Festplatte grundsätzlich nur 4 (physikalische) Partitionen aufnehmen Boot-Record Je Partition 1 x vorhanden Immer der erste Block der Partition Enthält Programm zum Laden des Dateisystems auf der Platte Wird eigentlich nur für die Betriebssystem-Partition (=aktive Partition) benötigt Steht aus Gründen der Vereinheitlichung in alle Partitionen zur Verfügung; d.h. in Datenpartitionen bleibt der BR ungenutzt. Die Zugriffsreihenfolge MBR == > Partitionstabelle == > Boot-Record Ist in nahezu allen n/dateisystemen einheitlich; die weiteren Zugriffe sind dann spezifisch auf das jeweilige Dateisystem zugeschnitten. BS_.odt Seite 41 von 54

42 4.2.2 Typischer Aufbau eines Dateisystems Abbildung 29: Aufbau eines Dateisystems in einer Partition Boot-Record Boot-Block Superblock Freispeicherverwaltung Boot-Record (siehe oben) Je Partition 1 x vorhanden Immer der erste Block der Partition Enthält Programm zum Laden des Dateisystems auf der Platte Wird eigentlich nur für die Betriebssystem-Partition (=aktive Partition) benötigt Steht aus Gründen der Vereinheitlichung in alle Partitionen zur Verfügung; d.h. in Datenpartitionen bleibt der BR ungenutzt. Enthält alle Schlüsselparameter des Dateisystems Wird beim Systemstart (bzw. bei ersten Zugriff auf das Dateisystem) in den Arbeitsspeicher geladen Enthält die "Magic-Number" zur Identifizierung des Dateisystems Enthält Angaben über die die Gesamtzahl der Blöcke im Dateisystem Enthält administrative Schlüsselinformationen Enthält Informationen über freie und belegte Blöcke im Dateisystem Realisiert als Bitmap oder als Liste von Zeigern BS_.odt Seite 42 von 54

43 I-Nodes Realisiert als Array-of-Records Je Datei ein Record Enthält alle Informationen über die Datei (z.b.: Dateiname, Eigentümer, Zugriffsrechte, erstellungs-, Änderungs-, Verfalldatum, Adresse des ersten Blocks der Datei, Dateigrösse, ) Wurzelverzeichnis Hauptverzeichnis der Partition als Spitze des Verzeichnisbaums restliche Partition Der Rest der Partition enthält die Dateien und ggf, weitere Unterverzeichnisse Realisierung von Dateien Literaturhinweise: [Tann02] Kap , Seite 429 ff Die technische Realisierung von Dateien muss einige zentrale Problemstellungen berücksichtigen: Welche Blöcke gehören zu einer bestimmten Datei? In welcher Reihenfolge ergeben die Blöcke die Datei? Welche Blöcke sind noch frei? Wie werden Blöcke, die nicht mehr benötigt werden (z.b.: nach dem Löschen einer Datei) wieder freigegeben? Zur Erfüllung dieser Aufgaben gibt es unterschiedliche Lösungsansätze, die hier zum Teil kurz vorgestellt werden sollen. BS_.odt Seite 43 von 54

44 Datei als Menge von zusammenhängenden Blöcken Abbildung 30: Blockaufteilung einer Festplatte Beispiel: Dateigröße Blockgröße benötigte Blöcke 50 kb 1 kb 50 Stck BS_.odt Seite 44 von 54

45 Abbildung 31: Dateien als Folge von Blöcken Diese Art der zusammenhängenden Speicherung hat einige Vorteile: Einfache Implementierun Es genügt, den ersten Block und die Anzahl der Blöcke zu kennen Gute Leseperformance die gesamte Datei kann in einem Lesevorgang gelesen werden. Jedoch sind auch einige gravierende Nachteile mit dieser Speicherungsmethode verbunden: Zunehmende Fragmentierung der Platte Beim Löschen von Dateien entstehen Lücken Vergrößerung einer bestehenden Datei ist nicht (oder nur mit hohem technischen bzw. organisatorischen Aufwand) möglich. BS_.odt Seite 45 von 54

46 Abbildung 32: Dateifragmentierung Einsatzbereiche: CD-ROM Magnetische Bänder BS_.odt Seite 46 von 54

47 Datei als verkettete Liste von Blöcken Literaturhinweise: [Tann02] Kap , Seite 431 ff Abbildung 33: Datei als verkettete Liste von Blöcken Charakteristische Merkmale: Das erste Wort eines jeden Blocks wird als Zeiger (Adresse) des nächsten Blocks verwendet Der Rest des Blocks steht als Datenbereich zur Verfügung Vor- und Nachteile: Jeder beliebige Block kann für die Datei verwendet werden Physikalische Reihenfolge der Blocks ist ohne Bedeutung Kein Verlust von Speicherplatz durch Fragmentierung Im Verzeichniseintrag genügt die Adresse des ersten Blockes Lesevorgang sehr langsam, da immer erst alle diejenigen Blöcke gelesen werden müssen, die vor dem gesuchten Block stehen. Der verfügbare Speicherplatz ist keine Zweierpotenz mehr, da Platz für den Folgezeiger abgezweigt werden muss. Erhöhter Verwaltungsaufwand bei Kopiervorgängen, da Verkettungsinformationen berücksichtigt werden müssen. BS_.odt Seite 47 von 54

48 Datei als verkettete Liste in einer Hauptspeichertabelle (FAT) Die Realisierung erfolgt ebenfalls als verkette Liste von Speicherblöcken. Die Verkettungsinformationen (Zeiger auf den Folgeblock) werden jedoch in einer Tabelle im Hauptspeicher gehalten. Diese Hauptspeichertabelle nennt man "File Allocation Table" (FAT). Die im vorherigen Kapitel genannten Nachteile der verketteten Liste entfallen dadurch. Abbildung 34: FAT - File Allocation Table Doch auch diese Lösung hat noch einige Nachteile: Die FAT muss komplett in Arbeitsspeicher (incl. Virtueller Speicher) gehalten werden Rechenbeispiel: Eine 20 GB-Platte mit Blöcken zu je 1 kb würde ca. 20 Mio. Einträge erfordern. Da ja in jeden Eintrag auch die größte Nummer untergebracht werden muss, werden für jeden Eintrag 4 Bytes benötigt. D.h. es werden für die FAT ca. 80 MB Hauptspeicher benötigt. BS_.odt Seite 48 von 54

49 Zwischenzeitlich wurden mehrere FAT-Versionen entwickelt FAT FAT16 FAT-32 Ursprüngliches FAT In "alten" MS-DOS-Systemen verwendet Adresslänge: 16 Bit; d.h nur 216 (=65535) Blöcke adressierbar Die entspricht einer maximal adressierbaren Plattenkapazität von 32 MB (bei 512 Byte großen Blöcken) Bei größeren Platten müssen größere Blockungsfaktoren verwendet werden == > größerer Speicherverschnitt Maximale Plattenkapazität bei FAT-16 ca. 32 MB (512 Byte je Block) bzw. 2 GB (bei 32 kb je Block) Weiterentwicklung von FAT Typische Vertreter: WINDOWS-95/98/ME Adresslänge: 32 Bit; d.h 232 (ca 4,3 Mrd) Blöcke adressierbar Die entspricht einer maximal adressierbaren Plattenkapazität von ca. 2 TB NTFS Literaturhinweise: [Tann02] Kap , Seite 884 ff ################################################# # wird ggf. noch ergänzt ################################################# BS_.odt Seite 49 von 54

50 I-Nodes Literaturhinweise: [Tann02] Kap , Seite 433 ff Merkmale: Jeder Datei wird eine Datenstruktur (I-Node = Index-Node) zugeordnet Die I-Node enthält die Attribute der Datei und die Adressen der Datenblöcke Abbildung 35: i-nodes BS_.odt Seite 50 von 54

51 Vor- und Nachteile: Der i-node muss nur dann im Arbeitsspeicher stehen, wenn auf die Datei zugegriffen werden soll. Dadurch entsteht ein erheblich geringerer Arbeitsspeicherbedarf. Bei FAT wächst der Arbeitsspeicherbedarf mit der Größe der Festplatte; bei i-nodes ist der Arbeitsspeicherbedarf nur von der Anzahl der geöffneten Dateien abhängig (und nicht von der Plattengeometrie). Jeder i-node kann nur eine begrenzte Anzahl an Plattenadressen aufnehmen; bei großen Dateien (mit vielen Datenblöcken) kann dies zu einem Problem werden. Abhilfe: die letzte Adresse verweist nicht auf einen Datenblock sondern auf einen Block der die weiteren Adressen enthält. Diese Weiterleitung kann nahezu beliebig fortgesetzt werden. Abbildung 36: Dateizugriff mit i-nodes Anwendung für I-Nodes: UNIX / LINUX-Dateisysteme BS_.odt Seite 51 von 54

52 5. mit LINUX 5.1 Backup und Recovery ################################################# # wird noch ergänzt ################################################# # # # # Logische und physikalische Sicherung Komplettsicherung Differenzsicherung Dump BS_.odt Seite 52 von 54

53 6. mit WINDOWS 6.1 Backup und Recovery ################################################# # wird noch ergänzt ################################################# # # # # Logische und physikalische Sicherung Komplettsicherung Differenzsicherung Dump BS_.odt Seite 53 von 54

54 7. Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1: Was sind Daten?...4 Abbildung 2: Anforderungen an die Verwaltung von Daten...5 Abbildung 3: gängige Diskettenformate...6 Abbildung 4: Aufbau einer Diskette...7 Abbildung 5: Speicherkapazität von Disketten...8 Abbildung 6: Festplatten...9 Abbildung 7: Aufbau einer Festplatte...10 Abbildung 8: Schreib-/Lesekopf...10 Abbildung 9: Magnetband als Massenspeicher...11 Abbildung 10: Aufbau eines sequentiellen Bandspeichers...12 Abbildung 11: Anforderungen an die Verwaltung von Daten...13 Abbildung 12: Dateiverwaltung durch das Betriebssystem...15 Abbildung 13: Der Dateibegriff...16 Abbildung 14: Dateinamen unter MS-DOS...17 Abbildung 15: Einige wichtige Extensions...17 Abbildung 16: Dateistruktur: sequentielle Dateien...19 Abbildung 17: Dateistruktur: indexsequentielle Dateien...21 Abbildung 18: Dateistruktur: Baumstruktur...22 Abbildung 19: Aufbau einer Datei unter UNIX / LINUX...25 Abbildung 20: Verzeichnissystem mit einer Ebene...27 Abbildung 21: Verzeichnissystem mit zwei Ebenen...29 Abbildung 22: Hierarchisches Verzeichnissystem mit mehreren Ebenen...30 Abbildung 23: Das LINUX-Verzeichnissystem...31 Abbildung 24: Operationen auf Verzeichnissen...35 Abbildung 25: Rolle des Betriebssystems beim...37 Abbildung 26: Zugriffe auf Dateisystem und Festplatte...38 Abbildung 27: Aufbau einer Festplatte...39 Abbildung 28: physikalische Partitionen einer Festplatte...40 Abbildung 29: Aufbau eines Dateisystems in einer Partition...42 Abbildung 30: Blockaufteilung einer Festplatte...44 Abbildung 31: Dateien als Folge von Blöcken...45 Abbildung 32: Dateifragmentierung...46 Abbildung 33: Datei als verkettete Liste von Blöcken...47 Abbildung 34: FAT - File Allocation Table...48 Abbildung 35: i-nodes...50 Abbildung 36: Dateizugriff mit i-nodes...51 BS_.odt Seite 54 von 54