Datei-verwaltung.

Präsentation zum Thema: "Datei-verwaltung."—  Präsentation transkript:

1 Datei-verwaltung

2 Dateisysteme Liste von Dateien auf Massenspeicher
= relationale Datenbank! Objektorientierte Datenbank: mit Methoden+Attributen Multi-Media-Datenbank: mit Bild+Tonobjekten+Synchron. Organisation von Datenbanken Persistent Storage Manager PSM (kleineObjekte) Object-Oriented Database Management System OODBMS Nummer Name Position Länge Datum ... Datei1.dat 264 1024 1 MyProgram 234504 550624 2 Datei1.dat 530 2048 ... ... ... ... ... ... Datei gleichen Namens, zu viele Namen: kein Problem für Datenbank (untersch. Schlüssel), aber für Menschen! Also: Hierarchische Organisation der Namen. Dateiverwaltung

3 Dateinamen und Attribute
Dateistrukturen Dateiarten Dateiimplementierung Dateiverwaltung

4 Dateinamen Hierarchische Dateiorganisation in Baumform
Knoten = „Ordner“ = directory gleiche Dateinamen möglich Alle Dateien Gruppe 1 Gruppe m Datei f 2 ... Datei n ... Datei s Zusätzliche Vernetzung Firma Abteilung 5 Formulare Rudi Hans BriefVorlage.dot Brief1.doc .. BriefN.doc Brief1.doc BriefM.doc “Wald” (azykl.Graph) Dateiverwaltung

5 Dateinamen Namensbildung Name.ext (üblich) Beispiele:
Extension = Dateityp, Dateizweck Beispiele: .dat Daten; Format hängt vom Erzeugerprogramm ab .doc Textdokument in dem speziellen Format des Texteditors .pas PASCAL-Programm Quellcode .c C-Programm Quellcode .h Deklarations (header)-Dateien für C-Programme .ps Postscript Dateien zum Ausdrucken .Z, .zip, .gz Komprimierte Dateien nicht genormte Endung! .tar ein gesamtes Dateisystem, in einer Datei abgespeichert .html ASCII-Textdatei für das world wide web-Hypertextsystem .jpg, .gif, png, Bilddateien (komprimiert/unkomprimiert) .tif, .bmp MS-DOS: 3 Extensionsbuchstaben! Sonst: Char ohne \ / : * ? " < > Dateiverwaltung

6 Dateinamen: Externe Typangabe
Geschachtelte Typen Beispiel: Skript.ps.gz = Textdatei  Postscript-FormatKomprimiert Typaktionen Typ verknüpft mit Aktion Benutzeroberfläche (Desktopmanager HP -VUE, MS-Explorer) behandelt Dateinamen Liste von Aktionen pro Typ definiert (Kontextmenü) Doppelklick = erste Aktion ausführen Dateiverwaltung

7 Dateinamen: UNIX Interne Typangabe
class File Header { a_magic: LONG CARDINAL (* Magische Zahl *) a_txt: CARDINAL (* Code-Segmentgröße *) a_data: CARDINAL (* Segmentgröße der init. Daten*) a_bss: CARDINAL (* Segmentgröße der nicht init.Daten*) a_syms : CARDINAL (* Größe der Symboltabelle*) a_entry: CARDINAL (* Start des Programms*) ... } a_magic = 407B (* altes Format: Code („text“) und Daten werden nicht schreibgeschützt und sollen deshalb nicht von anderen Prozessen genutzt werden *) 410B (* Text-Segment wird schreibgeschützt, und das Datensegment wird an die nächsten Seitengrenzen (4 KB) im Speicher gelegt *) 413B (* Text-Segment fängt an der nächsten Seitengrenze der Datei an; text und Datensegmente sind Multiple der Seitenlänge *) Dateiverwaltung

8 Dateinamen: Eindeutigkeit
Problem: eineindeutige Abbildung langer Namen auf kurze z.B. NTFS  MS-DOS (8 Zeichen.3Zeichen) Lösung Windows NT: Alle illegalen MS-DOS Buchstaben (Nicht-ASCII + Sonderzeichen) löschen, sowie alle Punkte innerhalb des Namens bis auf den letzten, falls er nicht abschließt. Kleinbuchstaben  Großbuchstaben. Nur die ersten 6 Buchstaben beibehalten, Zeichen „1“ vor dem Punkt einfügen. 3 Zeichen hinter dem Punkt beibehalten, alle anderen löschen. Ex. Datei gleichen Namens, so wird „1“ zu „2“ bzw. zu „3“, falls schon existiert. Beispiel: „Längerer Dateiname.text.ps“  LNGERE~1.ps Dateiverwaltung

9 Dateinamen absoluter Pfadname
Dateiname = Kette aus Knotennamen von der Wurzel zum Blatt Beispiel: /Abteilung5/Rudi/Brief1.doc Unix \Abteilung5\Rudi\Brief1.doc NT Vorgänger: .. Dieses Verzeichnis . relativer Pfadname z.B. Rudi/Brief1.doc bei Hans: ../Rudi/Brief1.doc Abteilung 5 Rudi Hans BriefN.doc Brief1.doc BriefM.doc Brief1.doc Der Vorteil relativer Pfadnamen besteht darin, daß sie unabhängig von der Namensgebung oberhalb und seitlich im Baum sind. Auch wenn Abteilung 5 in Abteilung 17 umbenannt wird, bleibt der relative, aber nicht der absolute Pfadname von Brief1.doc gleich. Dies ist besionders wichtig bei Compilern und ähnlichen Werkzeugen, die auf eine feste Arbeitsumgebung aus Dateien angewiesen sind. Dateiverwaltung

10 Dateinamen Vorteil relativer Pfadnamen: Portabilität
Beispiel Programmsystem / toolsX toolsY Daten Programme Dat1.a liba libb Prog Absolute Pfadnamen müssen nach Verschiebung des Programmsystems geändert werden, relative nicht ! Dateiverwaltung

11 Dateinamen: UNIX Pfaderweiterung
Einhängen eines Dateisystems (mounten) root file system / Festplatte 1 etc bin usr Zugriff mit /users/Rudi/Brief1.doc user file system Rudi Hans Ute Festplatte 2 Brief1.doc / users Frage: Was passiert mit den Dateien, die vorher in „users“ waren? Dateiverwaltung

12 Dateinamen: UNIX Namensraum
Baumorientiertes Dateisystem Querverbindungen durch hard links (gleiches Laufwerk) oder symbolic links (anderes Laufwerk) Beispiel : hard link löschen zu Datei2: Datei bleibt erhalten (Zähler). Problem: rück-referiertes Verzeichnis  stand-alone Verzeichnis? Abteilung5  Gruppe 1 Gruppe2 Der Unterschied in hard links und symbolic links macht sich beim Löschen deutlich: Löscht man Rud/Datei2 (hard link), so bleibt die Datei bestehen (link count>0), Nicht aber beim Löschen von Hans/Datei3: der symbolic link zählt nicht. Folge: „verwaiste“ symbolic links können existieren. Ein hard link Rudi -> Gruppe1 geht, so daß Löschen von Abteilung5 -> Gruppe1 geht. Problem!! Also: nur symbolic links auf Verzeichnisse! Rudi Hans hard link symbolic link Datei1 Datei2 Datei3 Dateiverwaltung

13 Dateinamen: Windows NT Namensraum
Namensraum für alle Objekte wie pipes, shared memory, Prozesse, Semaphoren, events, ... Logische Querverbindungen (symbolic links) ab NT 6.0 Löschen von Dateien: 2 Referenzzähler (user und kernel handles) „Durchsuchen“-Methode bei jedem Objekt: Einbindung neuer, unbekannter Dateisysteme möglich! (Vorteil ADT) Datei Löschen: 2 Zähler, einen für user (->Löschen im Namensraum) und einen für kernel (Speicher erst freigeben, wenn alle SysCalls beendet) Dateiverwaltung

14 Dateinamen: Windows NT Namensraum
Symbolic link parsing-Methode: \ Device Floppy0 DosDevices HardDisk0 A: B: C: Texte Partition0 bs_mem.doc bs_files.doc Objekt Manager Namensraum Dateimanager Namensraum Beispiel A:\Texte\bs_files.doc Objekt manager: A:\Texte\bs_files.doc  \Device\Floppy0\Texte\bs_files.doc Dateimanager: Methode Find ( Texte\bs_files.doc ) mit austauschbaren Methoden für FAT, HPFS, CD-ROM, EFS,... Symbolic link parsing-Methode: Angenommen, das Verzeichnis von Floppy A: soll gelesen werden. „A:“ wird ersetzt durch den symbolic link „\Device\Floppy0“ und dem Objektmanager übergeben. Dann wird stattdessen der Pfad „\Device\Floppy0“ abgearbeitet, bis wieder auf einen symbolic link gestoßen wird. In unserem Fall wird die „Durchsuchen“-Methode von Floppy0 ausgeführt, die im Floppy-Treiber enthalten ist und das FAT Dateisystem auslesen kann. Dies ermöglicht, auch sehr unterschiedliche Dateisysteme homogen einzubinden wie MS-FAT, HPFS von OS/2 oder CD-ROM Dateisysteme. Dateiverwaltung

15 Dateiattribute und Sicherheit
Dateilänge Datum für Erzeugung, letzte Änderung,.. Log. Attribute hidden, system, Archiv, Erzeuger, Besitzer, Benutzer und ihre Rechte Rechte & Sicherheit in POSIX-6: Geringst-möglichste Rechte für eine Aufgabe (least privilege) Diskrete Angaben für Zugangskontrolle: Wer darf, wer nicht (ACL) Zugangskontrolle nur von Prozessen größerer Rechte (mandatory control) Aufzeichnung des Zugangs (audit trail) Dateiverwaltung

16 Frage Kann man mit geeigneten Zugriffsrechten (ACL) Virenaktionen verhindern? Antwort Nein, da auch Systemprogramme mit großen Zugriffsrechten Fehler haben können Dateiverwaltung

17 Dateiattribute und Sicherheit: UNIX
Zugriffsrechte: Lesen R, Schreiben W, Ausführen X Verzeichnisse: r=Liste lesen, w=neue Datei aufnehmen, x=Liste durchsuchen nach Datei („ betreten“ des Verzeichnisses) Getrennt für Besitzer, Gruppe, Alle drwx r-x r-x brause 512 Apr23 15:55 . off May17 17:53 .. -rw- r-- r-- 44181 15:56 data1.txt Rechte bei Programmausführung = user Rechte Aber: set userId, set group Id system calls ACL ex. in neuerem Unix (Wer, was, wie) Dateiverwaltung

18 Dateiattribute und Sicherheit: Windows NT
Standardrechte: Read, Write, ExecuteOnly, Vollzugriff, ... ACL ex., neue Gruppen möglich Auditing möglich Speziell für Dateien: Attribute Dateiname, Gerätetyp, Position in Datei, share-Status(r,w,del) Mode: sync/async, mit/ohne Cache, seq/random Access, ... File disposition: temp oder persistent Methoden CreateFile(), OpenFile(), ReadFile(), WriteFile(), CloseFile() Lesen/setzen von Dateiinfo, Attributen, Geräteinfo, Verzeichnissen Sichern/freigeben der Dateilänge Attribute implementiert durch Datenströme, neu erzeugbar „MeineDatei.dat : MeinKommentar“ (aber: unsichtbare Viren!) Dateiverwaltung

19 Typische Dateifunktionen
Verbind.-orientierte Kommunikation Create File Name, Zugriffsart: Tabelleneintrag Open File Apprüfen der Zugriffsrechte, Puffereinrichtung, Close File Puffer + Tabellen deallozieren, Read/Write File Puffer schreiben/lesen: DMA! Seek File Index setzen der aktuellen Position  random access CreateFile, OpenFile, CloseFile implementieren eine verbindungsorientierte Kommunikation mit einer Datei. Dies läßt sich auch durch einen verbindungslosen Zugriff ersetzen, allerdings mit Overhead bei jedem read/write. Dateiverwaltung

20 Dateifunktionen: UNIX
fd = creat(Name, mode) file descriptor = Index in Tabelle fd = open (Name, mode) read (fd, bufadr, nbytes) write(fd, bufadr, nbytes) close(fd) Beispiel Dateideskriptoren in pipes fd=0: Standard Input, fd=1 Standard Output, fd=2 standard error Programm1 | Programm2 | .. | ProgrammN Dateiverwaltung

21 Dateifunktionen: Windows NT
Übliche Dateizugriffsfunktionen wie Unix Bei Veränderung der Dateistruktur: Atomare Transaktionen durch log file service LFS (write-ahead logging) Ergänzung der Operationen nach Absturz: = Fehlertolerantes Dateisystem Wirksam bei fail save-System, nicht aber bei aktivem Fehler Dateiverwaltung

22 Dateinamen und Attribute
Dateistrukturen Dateiarten Dateiimplementierung Dateiverwaltung

23 Strukturierte Zugriffsfunktionen
Sequentielle Dateien sequential files Magnetbänder, Lochstreifen z.B. put, get in Pascal Problem: unbekannte Zugriffsreihenfolge Wahlfreie Dateien random access files Festplatten, CD-ROM: Positionsangabe (offset) möglich Problem: ineffizient zum Suchen bei bekannter Datenorganisation Indexsequentielle Dateien index-sequential files Index Sequential Access Method (ISAM) von IBM, 1960/70 Übersicht (Index) am Dateianfang, Ordnung nach einem Kriterium (Schlüssel), z.B. Name, Geburtsdatum, ... Grundlage für MYISAM→MySQL, MS Active Directory, Access Fehlen der DB-Unterstützung: Problem bei UNIX! Indexsequenzielle Dateien sind wichtig, um große Datenbanken effizient zu unterstützen. Wahlfreier Zugriff reicht nicht (UNIX!), da Zwischenschicht nötig (erheblicher Programmieraufwand). Aber: Schnelle Portierung von UNIX auf bessere Prozessoren kompensierte diesen Nachteil Gegenüber etablierten Großrechnerbetriebssystemen. Dateiverwaltung

24 Indexsequentielle Dateien
Beispiel: Einwohnerdatei, Schlüssel = Alter Auffüllen von Containern der Größe m mit Schlüsseln Baumstruktur für indizierten Zugriff Index-sequentielle Speicherung (ohne Kopfbewegung: Zylinder, Spur, Sektor) Beispiel 12 Record-Schlüssel: 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 48 97 Index 1. Stufe Zylinder x 48 48<x 97 26 48 80 97 Index 2. Stufe Spur 26 26<x x 80 80<x Index 3. Stufe Sektor Datensätze Problem: Eingliedern/Ausgliedern von Datensätzen in die Container (Datenblöcke) fester Größe, z.B. „41“ Dateiverwaltung

25 Alu-Platte mit Eisenoxid
Festplattenmodell Schreib/Lese-Magnetkopf Schreib/Lesespur mit Sektoren Zylindergruppe: Spuren bei mehreren Platten Zylindergruppe Schreib-/Lesekopf Positionier- mechanik Drehachse Spur mit Se k toren Alu-Platte mit Eisenoxid Ein- und Ausgabeverwaltung

26 Indexsequentielle Dateien
Neuordnung Schnellerer Zugriff: Jeder Schlüssel wird nur einmal notiert und enthält bereits das Info für den Dateizugriff Pro Intervall ein Ast (oder Blatt), max. m Intervalle pro Knoten, m-1 Schlüssel Ist ein Schlüssel nicht vorhanden, wird er im Intervall auf unterster Stufe eingefügt und ein neues Blatt (Platzhalter) wird daneben erzeugt  Alle Blätter sind auf der selben Ebene Ist ein Behälter zu voll, so wird er in zwei Behälter aufgeteilt und der Schlüssel in der Mitte eine Ebene höher verschoben Beispiel: m=5 (max. 4 Schlüssel pro Knoten bzw. Schlüsselbehälter) Die 12 Record-Schlüssel 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 werden abgespeichert Dateiverwaltung

27 Indexsequentielle Dateien
Beispiel: m = Schlüssel 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 Eingliedern 5 Index 1. Stufe 15 26 42 48 Index 2. Stufe Dateiverwaltung

28 Indexsequentielle Dateien
Beispiel: m = Schlüssel 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 Schlüsselbehälter aufspalten 26 Index 1. Stufe 26 Index 2. Stufe Dateiverwaltung

29 Indexsequentielle Dateien
Beispiel: m = Schlüssel 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 Schlüsselbehälter auffüllen 26 Index 1. Stufe 56 80 82 Index 2. Stufe Dateiverwaltung

30 Indexsequentielle Dateien
Beispiel: m = Schlüssel 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 Schlüsselbehälter teilen 26 80 82 56 Index 1. Stufe 56 Index 2. Stufe Dateiverwaltung

31 Indexsequentielle Dateien
Beispiel: m = Schlüssel 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 Schlüsselbehälter auffüllen 26 80 82 56 Index 1. Stufe 37 50 97 Index 2. Stufe Dateiverwaltung

32 Allgemein: Einfacheres Einfügen neuer Schlüssel
B-Baum Allgemein: Einfacheres Einfügen neuer Schlüssel Intervall (Ast oder Blatt) suchen für neuen Schlüssel Einfügen auf unterster Stufe in einen Behälter Behälter bereits voll (ex. m-1 Schlüssel) : Aufteilen in zwei Behälterhälften und Einzelschlüssel [S1...St-1], St, [St+1...Sm] mit t = m/2 Mittleren Schlüssel St nach oben verschieben in höhere Stufe Bei Überlauf im Behälter der höheren Stufe wie oben verfahren Eigenschaften Gleiche Anzahl von Verzweigungen pro Behälter pro Ebene Schlüsselbehälter sind mind. zur Hälfe ( m/2 ) voll  „B-Baum“ Dateiverwaltung

33 B-Baum Definition B-Baum (Bayer, McCreight 1972)
Ein B-Baum der Ordnung m ist ein Baum, bei dem die Wurzel (wenn sie nicht Blatt ist) mind. 2 und max m Äste hat jeder Knoten mit k Verzweigungen k–1 Schlüssel (Indizes) enthält, jeder Ast bzw. Knoten (bis auf die Wurzel und Blätter) in minimal k = m/2 und maximal k = m Äste verzweigt, (minimal zur Hälfte gefüllte Behälter) alle Blätter auf derselben Ebene sind. Die Blätter selbst tragen keine Information; sie stellen nur mögliche Einfügepunkte für Indizes dar. Satz: Bei N Schlüsseln gibt es N+1 Blätter Dateiverwaltung

34 B-Baum Anzahl der nötigen Stufen (Baumtiefe) (ungerades m)
1.Stufe: mind. 2 Verzweigungen der Wurzel nötig 2.Stufe: mind. 2 mal m/2 Verzweigungen auf der Stufe 3.Stufe: mind. 2 mal m/2 mal m/2 Verzweigungen n-te Stufe: mind. 2m/2m/2.. = 2m/2n–1 Verzweigungen = N+1 Blattverzweigungen Wir erreichen spätestens in der n-ten Stufe 2m/2n–1 = N+1 Verzweigungen. Also: 2m/2n–1 = N+1 n–1 = logm/2 (N+1)/2 Log. Suchzeit! Beispiel Bei m=200, N=2 Mill.: max. n-1 = log100(1106)=log100(1003) = 3 Stufen, also nur max. n=4 Stufen! B-Bäume sind flach ! Wie schnell verzweigt der Baum, so daß die N+1 Blätter erreicht werden? Auf jeder Stufe muß er mindestens m/2 verzweigen, so daß auf der n-ten Stufe für jedes Blatt eine Verzweigung genau dann existiert, wenn die min. Anzahl der Verzweigungen > Blätterzahl ist. Dateiverwaltung

35  Jede Partition ist nicht mind. ½, sondern 2/3 voll
B-Baum Problem: Häufiges Teilen der Behälter Verbesserungen: Ausgleich zwischen vollen und leeren Behältern Verschiebe vom Schlüsselbehälter mit m–1 Schlüsseln zu einem Nachbarbehälter mit k < m-1 Schlüsseln so, dass jeweils die halbe Gesamtschlüsselzahl verbleibt und der mittlere Schlüssel mit Index i= (k+m)/2+1 nach oben wandert. Aufteilen von zwei vollen Behältern in drei Behälter Teile vollen (m-1) und übervollen (m) Behälter + dazugehörenden Schlüssel der nächsthöheren Stufe (=2m) in drei Behälter auf zu je (2m-2)/3 Schlüssel, sowie 2 für die nächste Stufe. Also jeweils (2m–2)/3, (2m–1)/3 und (2m)/3 Schlüssel, wobei die beiden Schlüssel SA und SB mit den Indizes A= (2m-2)/3 +1, B = A + (2m–1)/3 +1 nach oben in die höhere Indexstufe wandern.  Jede Partition ist nicht mind. ½, sondern 2/3 voll Dateiverwaltung

36 B*-Baum Definition B*-Baum
Ein B*-Baum der Ordnung m ist ein Baum, bei dem die Wurzel mindestens 2 und maximal 2 (2m–2)/3 +1 Verzweigungen hat. Damit kann die Wurzel beim Überfließen in 2 Behälter zu je (2m–2)/3 Schlüssel (plus ein Schlüssel als neue Wurzel) geteilt werden. jeder Ast bzw. Knoten (bis auf die Wurzel und Blätter) in minimal k = (2m–1)/3 und maximal m Äste verzweigt. jeder Knoten k–1 Schlüssel (Indizes) enthält. alle Blätter auf derselben Ebene sind. Dateiverwaltung

37 Beispiel B*-Baum Beispiel: m = Schlüssel 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 B*-Baum: Eingliedern in Wurzel mit max 2 (2m–2)/3 = 4 Schlüsseln 5 Index 1. Stufe 15 26 42 48 Index 2. Stufe Dateiverwaltung

38 Beispiel B*-Baum Beispiel: m = Schlüssel 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 B*-Baum: Wurzel-Schlüsselbehälter aufspalten 26 Index 1. Stufe 26 Index 2. Stufe Resultiert in 2 Behälter je (2m–2)/3 = 2 Schlüssel wie beim B-Baum Dateiverwaltung

39 Beispiel B*-Baum Beispiel: m = Schlüssel 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 B*-Baum: Überfließen 5 15 48 42 26 56 80 82 97 5 42 26 15 48 56 80 82 26 15 5 42 48 Index 1. Stufe 56 80 97 82 Index 2. Stufe Dateiverwaltung

40 B*-Baum: Beispiel Beispiel: m = Schlüssel 5, 15, 26, 42, 48, 56, 80, 82, 97, 37, 50 B*-Baum: Behälter dreiteilen 48 26 56 Index 1. Stufe 37 80 26 5 15 56 82 97 42 Index 2. Stufe m=5 (2m-2)/3= (2m-1)/3 = (2m)/3 =3 Dateiverwaltung

41 B-Baum vs. B*-Baum Vergleich B-Baum vs. B*-Baum m=5
Beispiel: Aufbau + Einfügen von „41“ m=5 Wird ein weiterer Schlüssel zur Wurzel des B*-Baums hinzugefügt, so fließt der Container über und es entstehen 2 Container mit je 2 Schlüsseln sowie eine neue Wurzel. Eingefügt wird immer nur auf der 0.Stufe bei einem Einfügepunkt (Intervall). Fazit: B*-Baum hat besseren Füllgrad  weniger Behälter nötig Dateiverwaltung

42 Dateinamen und Attribute
Dateistrukturen Dateiarten Dateiimplementierung Dateiverwaltung

43 Mehrfachlisten und Invertierte Dateien
Die Indexfolge jeder Schlüsselart ist als Liste implementiert Beispiel: Mehrfachliste (z.B. für Alter, Größe, ..) Indexfolge 1, 3, 2, 6, 5, 8 Problem: Sequentielle Schlüsselsuche Lösung: Alle Zeiger im Dateianfang: invertierte Datei (SchlüsselRecord, statt umgekehrt) Dateiverwaltung

44 Bibliotheksdateien die nicht im Kern sind
= BS-typische, von allen Prozessen nutzbare Funktionen, die nicht im Kern sind Vorteile weniger Hauptspeicher nötig, da Modul nur einmal vorhanden Wartung ist erleichtert, da zentral Aber: Speicher wird billiger & wenige Module sind oft benutzt Anfangsadresse Null nicht immer möglich  relozierte Kopien nötig Wartung ist bei zentraler Verteilung lokaler Kopien einfacher DLL-Hölle: Mehrere Module gleicher Version bilden eine Gruppe & Verschiedene Programme benötigen unterschiedliche Funktionalität von Modulversionen gleichen Namens & kein Schnittstellencheck  CRASH unklarer Herkunft ! Also: Bibliotheksmodule bei Applikation lassen registrierte Systembibliotheken automatisch reparieren (WIN 2000: 2800 signierte System-DLLs) Dateiverwaltung

45 memory mapped files Idee: wahlfreier Zugriff auf Massenspeicher = RAM
Plattenspeicherblöcke  Hauptspeicherseiten paging Datei auf Platte virt. Adreßraum im Hauptspeicher Daten header code stack Semaphoroperationen für gemeinsame Prozeßnutzung möglich Vorteile: Einlesen des Bereichs nur wenn nötig (ohne Kopie) Pufferung automatisch durch Paging (kein extra Cache nötig) Problem: Änderung der Länge der Datei auf Platte Dateiverwaltung

46 memory mapped files Beispiel Unix
mmap() stellt eine Abbildung von virtuellem Adreßraum in den Bereich einer Datei her. munmap() beendet die Abbildung. Wurde der Speicherinhalt verändert, so werden die veränderten Seiten auf die Datei zurückgeschrieben. msync() aktualisiert die Datei aus dem Speicher. Außerdem: Semaphor-Operationen zur Synchronisation Beispiel Windows NT VM-Manager & I/O-Manager CreateFileMapping() erzeugt ein Objekt OpenFileMapping() öffnet es anderen Prozesse unter dem Namen MapViewOfFile() Teilbereiche daraus in den virt. Adreßraum abb. FlushViewOfFile() aktualisiert den Dateibereich UnmapViewOfFile() wieder schließen Dateiverwaltung

47 special files Abbildung von Dateimechanismen auf Gerätesteuerung
Öffnen/Schließen von Dateien = Initialisierung der Geräte Lesen/Schreiben von Daten = I/O der Daten Statusänderung der Datei = Statusänderung des Geräts Beispiel Unix „/dev/tty“ Terminal ein/ausgabe (character-oriented) „/dev/mt“ Magnetband (block-oriented) Open(),close(),read(),write() Ein Gerät, mehrere Namen und damit Modi (sequentiell, random access) möglich. Ioctl() Statusänderung, z.B. Übertragungsmodus&Geschwindigkeit Mount() Wurzelknoten des Dateisystems auf Gerät ersetzt Datei Beispiel Windows NT virtual files Zugriff auf Geräte, Netzwerkverbindungen etc. wie auf normale Dateien Dateiverwaltung

48 Dateinamen und Attribute
Dateistrukturen Dateiarten Dateiimplementierung Dateiverwaltung

49 Dateiimplementierung
Kontinuierliche Speicherzuweisung Datei „in einem Stück“: Schnell, aber nicht änderbar. Listenartige Speicherzuweisung Verzeigerte Liste von Speicherblöcken (Strategien!) Vorteil Rekonstruktion möglich bei Anker-Löschung Nachteil ineffizienter wahlfreier Zugriff, da nur sequentiell möglich Datei A Datei B Nil B Block 0 A Block 1 Block 2 Block 3 1 2 3 4 5 6 Dateiverwaltung

50 Dateiimplementierung
Zentrale indexbezogene Speicherzuweisung zentraler Block von Zeigern (Indizes) in einer Liste Phys. nächster BlockNr = ListenIndex D a ten- block 2 Anfang Datei B 1 5 2 3 Anfang Datei A 3 6 4 1 5 7 6 NIL Ende Datei B Dateiverwaltung

51 Beispiel: Zentraler Index
Beispiel File Allocation Table FAT von MS-DOS Blockgröße: 512 Byte (= 1 Sektor), Block 0: Bootstrap, Blöcke 1-5: FAT mit je Eintrag 12 Bit = 3 Hexzahlen = 1.5 Byte pro Eintrag Blöcke Wurzelverzeichnis Pro cluster 1024 Byte = 2 Blöcke Block 18/19 Block 20/21 Block 22/23 Maximale Diskettengröße max. FATgröße: 5 Blöcke512 = 2560Byte Max. Zahl der Einträge = 2560/1.5 = 1706 Einträge (cluster), also max 1706 Einträge 1024 Byte-Cluster = 1,7 MB pro Diskette Cluster 0 Index 2 Index 3 Cluster 1 Index 4 Die FAT ist nochmals repliziert als Sicherungskopie in den Blöcken 6-10. Clustergröße = Speichergröße / Anzahl der Cluster Anzahl der Cluster = Anzahl der Indizes = max. Anzahl der Einträge, bestimmt durch Bitbreite eines Eintrags 12 Bit Eintrag = 2^12 Einträge, 16 Bit Eintrag = 2^16 Indexeinträge = 2^16 Cluster Index 5 Cluster 2 Index 6 12 Bit 1024 Byte Dateiverwaltung

52 Beispiel File Allocation Table FAT von MS-DOS (Block 11-17)
Beispiel: FAT Beispiel File Allocation Table FAT von MS-DOS (Block 11-17) 32 Byte-Verzeichniseintrag (16 Stück pro 512 Byte-Sektor) DateiName.ext A reserved tim dat st len A = 8 bit-Bitmap, 1 = wahr 0 = falsch Datei nur lesen verborgen Systemdatei Gerätename, nicht Dateiname Unterverzeichnis Archive Reserviert Unterverzeichnis = Datei mit Verzeichniseinträgen Dateiverwaltung

53 Beispiel: Zentraler Index
FAT-Probleme bei Platten Indexgröße Floppy 12 Bit  Platten 16 Bit 212 Einträge  216 Einträge = 216 Cluster Problem1: zu wenige Cluster Bei 2 GB Platte und 216 Cluster ist Clustergröße = 2 GB/Clusterzahl = 231/216 = 215 = 32kB groß: großer Verschnitt von 16kB! Problem2: zu kleine Cluster Bei 2 GB Platte und 1kB Clustergröße  231/210 = 221 = 2 Mill. Einträge. Da jeder Eintrag 2 Mill andere Einträge referieren kann, muss er mind. 21 Bit (3 Bytes) breit sein. Dies bedeutet 2 Mill. 3 Bytes = 6 MB Platz für die FAT-Tabelle im Hauptspeicher, ohne dass alle Einträge benutzt werden.  Bei kleinen Clustern gibt es lange Listen im RAM sowie lange Suchdauer. Dateiverwaltung

54 Implementierung Zentrale indexbezogene Speicherzuweisung
zentraler Block von Zeigern (Indizes) in einer Liste Phys. nächster BlockNr = ListenIndex D a ten- block 2 Anfang Datei B 1 5 2 3 Anfang Datei A 3 6 4 1 5 7 6 NIL Ende Datei B Problem: Lange Listen, unbenutzter Indexplatz Dateiverwaltung

55 Implementierung Verteilte indexbezogene Speicherzuweisung
Statt zentraler Index aller Dateien pro Datei eigene Indexliste: Datei A 4 1 5 7 ... Datei B 2 3 6 NIL Problem: Bei einigen Dateien ex. sehr viele Blöcke, lineare Blocksuche wird langsam. Dateiverwaltung

56 Implementierung Verteilte indexbezogene Speicherzuweisung
Baumstruktur zur schnellen Blocksuche Tabellengröße vs. Suchzeit: 1-,2-,3-stufige Tabellen Dateiverwaltung

57 Implementierung: UNIX
Zentrale Tabelle pro Datei: i-node (Indexknoten) z.B. EXT2 Verwaltungsdaten (Referenzen, Zeiger für free-Liste + mount()-Tabelle), erste Adressen von Datenblöcken + Zeiger für weitere Max 256 Einträge (Zeiger) 67 MB mode Max 256 Einträge (Blockindizes) 266 kB link count owner uid owner gid file size 3 time ref. 16,8 GB Adressen der e r sten 10 Blö c ke 1-indirekt 2-indirekt Die Speicherindizes reichen für 10 Blöcke=10 kB direkt Blöcke=266kB fach indirekt 10+256mal256 = 10kB+216kB=67MB 2-fach indirekt kB = 16,8 GB 3-fach indirekt 3-indirekt Verzeichnis = Datei = Tabelle aus Dateinamen + i-node-Nummer Zentrale Tabelle aller i-nodes = super node Dateiverwaltung

58 Implementierung: UNIX
LINUX Dateisystemkonzept Prozess 1 Prozess 2 user mode kernel mode directory cache dcache syscalls: create, open, close, lseek, read, write, stat Virt.Datei-system VFS v-node cache Dateisystem ca. 20 Stck Minix Ext2 Reiser Proc . . . Das virtuelle Dateisystem ist die einheitliche Schnittstelle zu allen anderen Dateisystemen. Diese können per “hook” eingehängt werden und implementieren die Schnittstelle. Zur Zeit gibt es ext, ext2, xia, minix, umsdos, msdos, vfat, proc, smb, ncp, iso9660, sysv, hpfs, affs, ufs, sysfs, S5fs, Reiser, ffs,… Einheitlich gibt es Datenobjekte “v-nodes”, die Informationen der i-nodes der konkreten Dateisysteme aufnehmen können. Dabei ist dies ein abstraktes Konzept; die Kontrollinformationen können auch in Strukturen enthalten sein, in denen offiziell keine i-nodes existieren (z.B. DOS-FAT). Jeder Prozess greift auf ein dentry-Objekt zu, das im Verzeichnischache dcache vorhanden ist. Datencache Gerätetreiber tape disk1 disk2 D/A print . . . Dateiverwaltung

59 Dateiimplementierung: UNIX
LINUX- Beispiel EXT2 Dateisystem (1993) Blockgruppen (kopierte) Dateiinformationen Gruppe 0 Gruppe 1 … Gruppe N Super Block-Kopie Gruppenbeschreibung 1 Block Belegungs-Bitmap Inode Bitmap Inode-Tabelle Datenblöcke Dateiverwaltung

60 Dateiimplementierung: UNIX
LINUX- Beispiel EXT2 Dateisystem Gruppenbeschreibung (kopierte) Gruppeninformationen Deskriptor 0 Deskriptor 1 … Deskriptor M ADR (Block-Bitmap) ADR (inode Bitmap) ADR (Inode-Tabelle) Anzahl freier Blöcke Anzahl freier inodes Anzahl von Verzeichniseinträgen Dateiverwaltung

61 Dateiimplementierung: UNIX
LINUX- Beispiel EXT2 Dateisystem Verzeichniseinträge Inode-Index: 3 Nächster Eintrag Länge des Namens: 8 MeinName Inode-Index: 4 Nächster Eintrag Länge des Namens: 11 AndererName inode-Tabelle . .. 1 2 3 4 5 Die ersten beiden Einträge enthalten immer die Standardnamen “.” und “..” für das hiesige und das vorige Verzeichnis. Dateiverwaltung

62 Dateiimplementierung: Windows NT
Konzept Volumes (log. Massenspeicher) als Datenspeichereinheit Alle Untereinheiten eines volumes sind nur Dateien (files), gekennzeichnet durch eine 48 Bit-Zahl &16Bit-Sequenznummer Vorteile Dateien vs. dedizierte Blöcke (Plattenbereiche) einfacher, konsistenter Dateizugriffsmechanismus, sogar auf die boot-Information. Die Sicherheitsinformationen sind getrennt pro Objekt (Verwaltungsinformation)  besser anpaßbar an die inhaltlichen Notwendigkeiten des Objekts bzw. der Funktion. Werden Plattenteile unbrauchbar, so können die Verwaltungs-informationen unsichtbar für den Benutzer auch auf andere Plattenteile verlagert werden. Die Sequenznummer wird immer weitergezählt nach Löschen einer Datei, so daß auch zwei Dateien mit gleichem Namen unterscheidbar sind. Dateiverwaltung

63 Dateiimplementierung : MFT
Eigeneintrag Master File Table Datei 1 Eintrag Sicherheitskopie der MFT ( Plattenmitte) Datei 2 log file : Alle Operationen, die die NTFS - Struktur ändern, werden hier verzeichnet und garantieren so atomare Dat eitransaktionen. Datei 3 volume file : Statusinformationen Name, NTFS Version, ... corrupted Bit=1: Chkdsk-Programm Datei 4 attribute definition table: Attributstypen + ihr Status Datei 5 Root directory : Name des Wurzelverzeichnisses, z. B. \ Datei 6 bitmap file: Belegungstabelle der volume - Speichereinheiten (Cluster) Dies ist eine Übersicht über die Master File Table, eine Meta-Datenstruktur, die selbst wieder eine Datei ist. Datei 7 boot file: boots trap Code von Windows NT und die physikalische Geräteadresse der MFT -Datei. Datei 8 bad cluster file: Verzeichnis der unbrauchbaren volume Cluster - ~ ~ . . . Datei 16 Normale Benutzerdateien und Verzeichnisse Dateiverwaltung

64 Dateiimplementierung : Windows NT
Struktur eines Master File Table-Eintrags (eigentliche Datenblöcke) Lücke: Datenkompression! Security descriptor: Dieser ist ab Windows 2000 nicht mehr hier, sondern ausgelagert, um ein einziges Sicherheitsinfo für viele Dateien zu ermöglichen. Data stream: Er enthält alle neben den erwähnten Dateiattributen (ObjektID, volume name, index root bei Verzeichnissen) evtl. Zeiger zu weiteren MFT-Einträgen der selben Datei. Dateikompression: Existieren Speicherblöcke, die nur aus Nullen bestehen, und ist als Standardattribut „komprimiert“ für die Datei angegeben, so werden die leeren Blöcke nicht gespeichert. Statt dessen werden bei der Zählung der virtuellen Cluster die entsprechenden Clusterblöcke einfach übersprungen, so daß zwischen zwei VCN-Sequenzen „Löcher“ existieren. Beim Lesen der Daten wird dies vom NTFS-Dateisystem bemerkt und statt dessen entsprechende, mit Nullen initialisierte Blöcke zurückgegeben. Enthalten die Blöcke von „komprimiert“-Dateien keine Nullen, so wird ein allgemeiner Kompressionsalgorithmus angesprochen, der aber auf Schnelligkeit und nicht auf Kompressionsleistung optimiert wurde. Die Clustergröße variiert; sie beträgt 1 Millionstel der volume-Größe. Bei Volumegrößen > 32GB wechselt sie von 32kB auf 64 kB und bleibt so. Dateiverwaltung

65 Dateiimplementierung : Windows NT
Struktur des Wurzelverzeichnisses root directory root file Indexpuffer Standard VCN informat i on file 0, … file name „ \ “ 1 file 1, … file 4 VCN 2 file 3, … B*-Baum index root 4 file 6, … 3 file 10 file 15 5 file 8, … index alloc a tion VCN LCN 6 7 file 9, … Die file-Referenzen enthalten den fileID, Name, Zeitstempel, Länge etc, die aus der MFT kopiert sind. Die files sind in lex. Reihenfolge. VCN Max. 15 Dateien (Schlüssel) pro container (4 Cluster) bitmap XXX0XX0 8 file 11, … XXXXX 9 file 12, … ... 10 file 13, … 11 file 14, … Wurzelcontainer des B*-Baums Dateiverwaltung

66 Dateiimplementierung : Windows NT
Interne Datenstrukturen für eine NTFS-Datei NTFS disk database Object manager data NTFS memory data process stream file co n trol co n trol master file blocks block table file handle file table data object str e am file ... object user- ... defined attribute Hauptspeicher Massenspeicher Dateiverwaltung