Rechnerarchitektur und Betriebssysteme (CS201): Dateisysteme I + II

Transkript

1 Rechnerarchitektur und Betriebssysteme (CS201): Dateisysteme I + II 20 November 2012 Prof Dr Christian Tschudin Departement Mathematik und Informatik, Universität Basel Wiederholung / Diskussion 1 Was ist die Aufgabe eines Dateisystems? 2 Welche Ebenen unterscheidet man in einem Dateisystem? 3 Ist der Dateiname Teil einer Datei, oder Element eines Verzeichniseintrags? 4 Was ist der Unterschied zwischen einem symbolischen Link und einem Hard-Link 5 Warum möchte man für ein hierarchisches Dateisystem einen azyklischen Graphen? c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 2/29

2 Vorschau: UNIX inode für Dateiablage mode owners (2) timestamps (3) size block count direct blocks single indirect double indirect triple indirect c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 3/29 Oft gebrauchte Meta-Information: File-Typ File-Typ, um die richtige Applikation starten zu können Verschiedene Ansätze: Apple s HFS: resource fork der Datei beinhaltet explizit den Typ: CODE (ausführbares Programm), PICT (Bild), DITL (Dialog Box) Windows: Endung (*exe, *com, *jpg) Unix: Applikationen nutzen zum Teil Endung, sonst magic bytes in den ersten paar Bytes einer Datei: #!/bin/bash %!PS-Adobe-20 %PDF-14 (siehe man 1 file und man 5 magic ) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 4/29

3 Allokation von Dateispeicherplatz Dateien werden sequentiell geschrieben: Wie weiss man, ob noch genügend freier Platz auf dem Harddisk ist? Historischer Ansatze statische Allokation: Reservation einer maximalen Dateigrösse vor dem Schreiben: Ort der (zusammenhängen) Diskblöcke ist einfach festzulegen Ohne genügen grosse Lücke kann dies scheitern ev Dateien auf dem Harddisk herumschieben Kann auch heute noch Sinn machen bei read-only-dateisystemen, zb embedded Computing, Squash-File System Dynamisch Allokation: on-demand, dh man alloziert Diskblöcke so lange es geht Dann können aber Diskblöcke über die ganze Harddisk verstreut sein c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 5/29 Wie eine Datei auf Harddisk-Datenblöcke abbilden? Datei: Datenblöcke (typ 2-8 KBytes) 0 M-1 Harddisk: 0 N-1, üblicherweise M<<N Drei Strategien: Zusammenhängende (contiguous) Allokation Datei = Menge benachbarter Datenblöcke Verkettete Allokation Datenblöcke bilden eine verkettete Liste Index-Allokation Index der benutzen Blöcke c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 6/29

4 Zusammenhängende Allokation Notwendige Angaben sind: Startblock S Länge Random access ist einfach: Dateiblock n Harddisk Block S+n Beim Erstellen der Datei: Grösse muss dann festgelegt werden Fragmentierung der Harddisk beim Löschen von Dateien: Obwohl genügend freie Blöcke vorhanden sind, können neue Dateien nicht angelegt werden, wenn sie grösser als die grösste Lücke sind c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 7/29 Verkettete Allokation file jeep directory start 9 end 25 Verzeichnis enthält Nummer des ersten und letzen Harddisk-Block (Frage: warum ist das sinnvoll?) Jeder Harddisk-Block enthält Zeiger auf den nächsten Block Datei = verkettete Liste von Harddisk-Blöcken Kette für freie Blöcke c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 8/29

5 Eigenschaften der verketteten Allokation Sehr gute Nutzung freier Blöcke keine Lücken, keine Verluste schnell beliebig grosse Dateien Aber: schlechter random access -Zugriff: zuerst n 1 Blöcke einlesen, um Block n zu bekommen Variante: Alle Zeiger werden in einer Tabelle abgelegt wird bei MS/DOS verwendet: FAT - File allocation table Robustheit? FAT ist kritisch, hat oft zu Datenverlusten geführt c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 9/29 Indexierte Allokation Weiterhin Zeiger, aber nun in einer Tabelle (statt Liste) abgelegt: Datei besteht aus: Index-Block M Datenblöcke Zugriff auf Dateiblock i: Tabellen-Eintrag i (schnell!) index table Index-Block zu gross gewählt: Ineffizient bei kleinen Dateien Index-Block zu klein gewählt: zuwenig Platz für grosse Dateien c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 10/29

6 Indexierte Allokation (Forts) directory file jeep index block 19 Dateiverzeichnis enthält Adresse der Indextabelle (19) Dort die Adressen der eigentlichen Datenblöcke nachschlagen: 9, 16, 1 etc c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 11/29 Mehrstufige Indizes Um Index-Blöcke klein zu halten, aber grosse Dateien zu unterstützen: Multi-level Indizes: Index-Blöcke zeigen auf weitere Index-Blöcke Datei = Baum von Harddisk-Blocks Rechenbeispiel: sei HD-Block=2KB, bis zu 2 32 Blöcke wähle Index-Block=HD-Block: 4 Bytes/Eintrag 512 Einträge 1 Ebene: Dateigrösse max 512*2KB (1 MB) 2 Ebenen: Dateigrösse max 512*512*2KB (05 GB) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 12/29

7 UNIX: Hybride Index-Tabellen (inode) mode owners (2) timestamps (3) size block count direct blocks single indirect double indirect triple indirect c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 13/29 Verwaltung der freien Harddisk-Blöcke Bit map: ein Bit pro Block einfach, zusammenhängenden Bereich zu finden (warum wichtig?) Verkette Liste: Zeiger sind in den freien Blöcken gespeichert gut, um einzelne freie Blocks zu finden mühsam für zusammenhängenden Bereich Disk-crash: kann Speicherstruktur zerstören (inodes, free blocks) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 14/29

8 dskchk, scan, fsck file system check Bis vor einigen Jahren prekäre Situation: Dateisystem-Korruption (zb bei Bluescreen, Verlust Superblock) Ansätze: redundante FAT, redundante Superblocks UNIX: führt ein clean Bit wird gesetzt, wenn keine Daten im Hauptspeicher-Cache mehr zu schreiben sind (sync) File system check nötig, um verlorene Blöcke zu finden: UNIX: lost+found Verzeichnis, DOS: CHK Durch (Log-basierte) Journaling File Systems entschärft (NTFS, ext3) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 15/29 Sparse file = Datei mit Löcher (0-Bytes) Einfach abzubilden mit indexierter Allokation, von den meisten UNIX Datei-Systemen unterstützt (aber nicht ISO9600 CD-Format) Beispiele: core dumps noch nicht voll gefüllte Datenbank Wie solche Dateien erkennen? Demo für UNIX: - vergleiche Angabe von ls und du -s, oder - selbe Angaben mit stat finden Siehe spezielle Optionen bei cp, oder tar c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 16/29

9 Sparse Datei (Prog um zu experimentieren) #include <stdioh> int main() /* Sparse file creation */ { FILE *fp; fp = fopen("sparsedat", "w"); fseek(fp, ,seek_cur); /* 128 KB - 4 bytes */ fprintf(fp,"text"); fclose(fp); return 0; } Nur letzter Block hat Inhalt (Rest ist 0) Demo: sparse-option von cp, auto always never, und du (Geht nicht bei verschlüsselten Dateisystemen) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 17/29 File Descriptor Table Kernel muss Uebersicht behalten über alle offenen Dateien (Cache, Pufferverwaltung) System-weite open-file table führt alle momentan offenen Dateien, siehe auch lsof cached die Abblidung von Datei auf inode Per-Prozess Open-file table prozess-spezifische Daten wie Zugrifssmodus (r/w) aktuelle Lese/Schreibe-Position in der Datei File handle, descriptor : Integer-Wert als Index in diese Tabelle c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 18/29

10 Uebersicht: vom File-Descriptor zum Inode blocks read (4, ) sync tables of open files (per process) file-structure table in-core inode list inode list user space system space disk space c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 19/29 Dateisystem: Mount Bisher gesehen: 1 Harddisk-Partition mit 1 Dateisystem Ueblicherweise: mehrere Teil-Dateisysteme ZB: weitere HD-Partitionen Dateisystem im Netzwerk mount: Dateisystem in den lokalen Adressraum einklinken Windows: von CP/M geerbter expliziter Verweis auf Device (C:, D:) UNIX: 1 Baum c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 20/29

11 Dateisystem: Mount (Forts) / / /priv / /mnt /usr /mnt/cd /usr/bin CD Ein Dateisystem wird in ein anderes eingehängt: Zugriff auf Datei /mnt/cd/priv/dateiname Harddisk c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 21/29 Dateisystem: Virtual File System Betriebssystem muss mehrere Dateisystem-Typen unterstützen Virtual File System: Schicht zwischen logischem Dateisystem und den darunterliegenden (spezifischen) Ebenen (Speicherblock- und Device-Ebenen) NTFS FATxx ext2, ext3 iso9660 SMB http (!) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 22/29

12 Dateisystem: Virtual File System (Forts) root swap logical file system file systems logical devices physical devices c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 23/29 Dateisystem: Loop File System, Stackable FS Spezielles Device : loop Loop device: Datenblöcke werden nicht von einem Device geliefert, sondern von einem Softwaremodul Loop-Device-SW kann eigene Speicherblöcke verwalten: von einer Datei lesen (!) Kompression Verschlüsselung Beispiel: Dateisystem in einer Datei # mount -o loop testext3 /mnt/tmp c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 24/29

13 Dateisystem: RAID RAID = Redundant Arrays of Independent/Inexpensive Disks Diskblöcke mehrfach ablegen, um bei Disk-Crash Daten restaurieren zu können Stripping: Daten verteilen, zb 1 Disk für jede Bit-Position, 8 Disks RAID level 0: keine Redundanz RAID level 1: Disk Mirroring RAID level 2: Parity based error correction level 6: kann bis zu zwei HD-Ausfälle verkraften Hot spare : defekte Disk wird automatisch ersetzt c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 25/29 Dateisystem: /proc Dateisystem als Organisationskonzept von UNIX, /proc in Linux Hier: Namensraum verwenden, auch wenn keine eigentliche Dateien Alle Kernel-Daten: /proc/cpuinfo /proc/devices /proc/processnr Steckbrief der Maschine Liste Verzeichnis für jeden Prozess Einträge können zb mit cat gelesen oder mit echo beschrieben werden Windows: siehe Registry c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 26/29

14 Dateisystem: Named Pipes Pipes gehören nicht zu Dateisystemen: Pipes = interner (zeichenbasierter) Kommunikationskanal Betriebssystem-Aufruf: { int fd[2]; pipe(fd); // erzeugt pipe inode: fd[0] lesen, fd[1] schreiben erzeugt anonyme Pipe zb auch bei ls wc Pipe mit Name (FIFO): % mkfifo /tmp/thepipename c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 27/29 Dateisystem: File Locks Betriebssystem kann Dateizugriff schützen: file locks Dateien als shared resource : gleichzeitiger Zugriff von mehreren Programmen Zugriff schützen/kontrollieren: einen Lock anmelden kann den Prozess blockieren Vielzahl von Locks, zb SUN Solaris 2: kann sogar Datei-Regionen locken Siehe zb man 3 lockf (Posix file lock) c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 28/29

15 Dateisystem: Ausblick Es wäre noch viel zu sagen: read-only (CD: ISO-9660), write-once FS verteilte Dateisysteme: Andrew, NFS, Storage Area Network, Google-FS, Amazon S3, Hadoop für Big Data Indexierung (Google Desktop), Datenbank im OS (Longhorn) Integration mit Applikation ( -attachments nicht mehr mehrfach ablegen), Deduplifikation Verschlüsselte Dateisysteme, integriertes Backup, Versionierung, peer-to-peer, freenet, etc etc In Zukunft sind bei FS weiterhin Neuentwicklungen zu erwarten c Christian Tschudin CS201 Rechnerarchitektur und Betriebssysteme, , 29/29