Betriebssysteme 11/12

Transkript

1 Betriebssysteme 11/12 Dateisysteme 18. Jänner /43

2 Motivation RAM reicht nicht Hauptspeicher zu klein für alle Daten Information muss über Lebensdauer des Prozesses hinaus erhalten bleiben mehrere Prozesse sollen Informationen teilen Lösung: auf Festplatten oder Ähnlichem speichern Information persistent nicht von Prozessen abhängig. Verschwindet erst wenn gelöscht... Verwaltung durch Betriebssystem...also ein Dateisystem 2/43

3 Aus Benutzersicht Benutzer will in der Regel keine Details über wo und wie der Speicherung muss Dateien aber referenzieren können Namensgebung wichtig 3/43

4 Dateitypen reguläre Dateien ASCII-Dateien (Text) Binäre Dateien (meist interne Struktur) Verzeichnisse special files (/dev/..., /proc/...) block special files character special files 4/43

5 Dateizugriff sequentieller Zugriff alle Bytes nacheinander und zurückspulen Bandlaufwerk-kompatibel sequential access Einführung der Disketten: beliebige Reihenfolge möglich random access seek-system-call 5/43

6 Verzeichnisse Organisatorische Hilfe Verzeichnisse oder Ordner (directories, folders) Eine oder mehrere Ebenen 6/43

7 Eine Ebene A,B,C: Eigentümer (nicht Namen!) Früher auf PC s üblich, auch CDC 6000 (erster Supercomputer) Einfach fürs System. Nameclashes? 7/43

8 Zwei Ebenen Jedem Benutzer ein Verzeichnis Keine Namensprobleme. Nicht ausreichend... 8/43

9 Hierarchisches DS 9/43

10 Dateistruktur Interne Struktur unterschiedlich für das Betriebssystem meist nur Bytefolge andere Strukturen meist nur auf Mainframes Abbildung: Dateistrukturen, Beispiele 10/43

11 Implementierung Abbildung: Disklayout, klassisches Beispiel 11/43

12 Implementierung ( klassisch Unix ) Boot Block: Boot Loader, für Bootvorgang Super Block: Infos über das Dateisystem Partitionsgröße Blockgröße Zeiger auf freie Blöcke inode-nummer des Root-Verzeichnisses magic number (identifiziert FS-Typ)... index nodes (inodes) 1:1-Beziehung zwischen inodes und Dateien Datenblöcke 12/43

13 Implementierung ( klassisch Unix ) Platte in Blöcke gegliedert Blöcke in Zylindergruppen zusammengefasst eine Kopie des Superblocks je Zylindergruppe Daten einer Datei idealerweise in derselben Gruppe (Performance) Freier Speicher über Bitmaps verwaltet 13/43

14 inodes 14/43

15 Inode Attributes: type file, directory, character special file, block special file owner user, group time values created, last modified, last accessed size in bytes and blocks mode permissions (rwx) kein Dateiname! 15/43

16 Inode 10 (12) direkte Blockpointer für kleine Dateien ausreichend 1 indirekter Block: zeigt auf einen Block mit einer Liste von Blocknummern 1 doppelt indirekter Block: zeigt auf einen Block mit einer Liste von Blocknummern jede dieser Blocknummern ist ein Verweis auf einen Block mit einer Liste von Blocknummern 1 dreifach indirekter Block: zeigt auf einen Block mit einer Liste von Blocknummern jede dieser Blocknummern ist ein Verweis auf einen Block mit einer Liste von Blocknummern jede dieser Blocknummern ist ein Verweis auf einen Block mit einer Liste von Blocknummern 16/43

17 - 17/43

18 Inodes Dateien können mehrere Namen haben Verzeichnisse enthalten Namen und inode-nummer mehrfaches Auftreten zulässig hard link inode enthält link count Inode mit link-count 0: keine Referenz in Dateisystem mehr Datei kann entfernt werden Anzahl der inodes beschränkt Dateisystem voll weil kein freier Inode kein freier Block 17/43

19 ext/ext2/ext3/ext4 Dateisysteme für Linux Ursprünglich cross-development unter Minix Verwendung des Minix-Filesystems relativ sauber implementiert limitierte Plattengröße/Dateinamen VFS: virtueller file system layer erlaubt es, verschiedene Dateisysteme über dasselben Interface zu verwenden ext: extended file system (1992) erste Implementierung, die VFS unterstützt 2 GB Plattengröße 255 Byte Dateinamen Nachfolger: ext2 - ext3 - ext4 18/43

20 VFS Betriebssysteme 11/12 Abbildung: 18. Jänner 2011VFS Seite 19/43

21 ext2 Nachfolger von ext Übernimmt viele Ideen des Unix File Systems (UFS) kak Berkeley Fast File System (BSD FFS) Erweiterbarkeit als Designgrundsatz bis Kernel TB max. Volumegröße Verwendet Zylindergruppen, Superblock und inodes wie beschrieben 20/43

22 ext2 Attribute (Beispiele): c: compressed Datei wird komprimiert gespeichert s: secured Blöcke werden nach Löschen der Datei mit Nullen überschrieben S: synchronized Daten werden sofort auf die Festplatte geschrieben A: append mode Dateien werde immer im append-mode geöffnet 21/43

23 ext2 Fast symbolic links Dateinamen im inode gespeichert Status des Dateisystems dirty nach Absturz des OS, fsck empfehlenswert/erzwungen Regelmäßige fsck, auch wenn clean 22/43

24 ext2 performance Readaheads Mehr als ein Block wird von Festplatte angefordert Block-Groups Bei sequentiellen Dateizugriffen Bei Directory-reads inodes und Datenblöcke in der Nähe auf der Festplatte vermindert head-seek-times Preallocation Bei Zuordnung eines Blockes zu einer Datei werden bis zu 8 aufeinanderfolgende Blöche auf der Platte zugeordnet Verbessert write und read Zeiten 23/43

25 ext2 Verwaltung freier Einheiten inode allocation bitmap data allocation bitmap Maximale Dateigröße hängt ab von Blockgröße b min( b b 4 b=1kb: 16GB b=4kb: 2 TB 2 + b ) b, 232 b) 24/43

26 ext3 Basierend auf ext2 Journalisierendes Dateisystem Einfach gut getestet Unterschiede zu ext2 Journal Filesysteme können dynamisch wachsen HTree für große Verzeichnisse 25/43

27 ext3 Journal Änderungen an Dateien in ein Journal im wesentlichen eine zyklische Logdatei Zuerst ins Journal dann im Dateisystem Nach einem crash: Inkonsistenzen leichter reparierbar 26/43

28 Journal - ein typischer Ablauf Dateisystem konsistent Änderungen werden angefordert Änderungen im Journal aufgezeichnet Änderungen im Dateisystem nachgezogen Beispiel: Datei Löschen kann zwei Schritte benötigen: 1. Eintrag aus Verzeichnis entfernen 2. inode löschen Crash zwischen den Schritten: Verwaister inode Inkonsistenz Reihenfolge ändern? es zeigt ein Verzeichniseintrag auf nicht existenten inode später: inode wiederverwendet - kann fatal sein 27/43

29 Journal Ohne Journal: fsck - file system check vor nächsten Verwendung Jetzt: Einträge in Journal lesen Einträge nachziehen (falls nötig) Dateisystem rasch wieder konsistent Änderungen werden atomar entweder sie sind vollständig erfolgt (entweder davor, oder weil sie nach dem Crash nachgezogen werden) oder gar nicht (weil sie nicht vollständig ins Journal eingetragen wurden) 28/43

30 Journal-Implementierung Ort: unterschiedlich reguläre Datei (die auch wachsen kann) versteckte Datei, die nicht verschoben werden darf spezieller Bereich auf Festplatte getrenntes Device (SSD; NV-Ram) Journal fürs Journal Korrektheit der Einträge muss erkennbar sein Prüfsumme Einträge mit nicht korrekter Prüfsumme werden ignoriert 29/43

31 physical journal schreibt eine Kopie jedes Blockes zuerst ins Journal dann auf die Platte Crash: entweder weder im Journal noch auf Platte: keine Änderung nur im Journal: auf Platte nachziehen bereits auf Platte: nichts zu tun Hoher Overhead Kann für hohe Korrektheitsanforderungen in Kauf genommen werden 30/43

32 Logische Journale schreiben nur Metadaten ins Journal Tauschen Fehlersicherheit gegen Performance Kann zu Asynchronitäten zwischen Metadaten und Daten führen Beispiel: Filevergrößerung betrifft 1. inode (Größe) 2. free space bitmap (ein Block mehr reserviert) 3. neuen Block (Daten) In logischem Journal wird Schritt 3 nicht aufgezeichnet - kann zu korrekter Struktur aber Mist am Dateiende führen 31/43

33 Journale Schreibvorgänge auf Festplatte werden vom OS optimiert Könnte dazu führen, dass Journal nach Dateisystemänderunten auf die Platte geschrieben wird Synchronisation zwischen Kernel, Dateisystem und Treibern erforderlich Kann auch durch Festplatten-Firmware erfolgen Journalsystem muss daher flush der Plattencaches erzwingen 32/43

34 Journale in ext3 drei Level 1. Journal (geringstes Risiko) Daten zuerst ins Journal, dann auf die Platte. Daten müssen zweimal geschrieben werden. 2. Ordered (mittleres Risiko) Nur Metadaten gehen ins Journal, Dateiinhalte direkt ins Dateisystem. Änderungen an Metadaten werden erst als committed markiert, wenn Daten tatsächlich auf Platte Wenn nur Daten betroffen: kein Journal 3. Writeback(höchstes Risiko): Nur Meta-Daten. Nur Metadaten ins Journal, Dateiinhalte über sync-prozess. Gefahr von Datenverlust größer. Dateistruktur in allen drei Level gesichert. Keine Prüfsummen im Journal Inhalte nur in 1. 33/43

35 ext4 Nachfolger von ext3 Volumegrößen bis zu 1 exbibyte (2 60 ) Dateigrößen bis zu 16 tebibytes (2 40 ) verwendet Extents Preallocation allocate-on-flush Journal mit Prüfsumme 34/43

36 extents Bereich benachbarter Blöcke in Dateisystem Dateien werden nicht blockweise erweitert sondern gleich um mehrere Blöcke reduziert Fragmentierung bis zu 128 MiB pro Extent 4 extents im inode gespeichert weitere extents: H-Bäume 35/43

37 allocation pre-allocation Dateien bereits vorab in bestimmter Größe anfordern stehen dann vermutlich auf benachbarten Blöcken Entweder: Daten raufschreiben Besser: syscall fallocate() dynamic allocation traditionell: Blöcke sofort zuordnen jetzt: Daten in cache gespeichert, erst wenn sie auf die Platte geschrieben werden müssen, werden Blöcke zugewiesen verbessert die Performance Harmoniert ideal mit extents und dem multiblock allocator 36/43

38 btrfs Features Extent based file storage (2 60 max file size) Space efficient packing of small files Space efficient indexed directories Dynamic inode allocation Writable snapshots Subvolumes (separate internal filesystem roots) Object level mirroring and striping Checksums on data and metadata Compression (gzip and LZO) Integrated multiple device support RAID-0, RAID-1 and RAID-10 implementations Efficient incremental backup 37/43

39 btrfs Unteste Ebene verwaltet Speicherpool können mehrere block devices sein Verwaltung in Chunks (1 GiB) für die höheren Ebenen Mehrere Dateien in einem Chunk Eine Datei auf mehrere Chunks verteilt RAID (redundant array of independent disks) hier auf chunk-level RAID-1 (mirroring): zwei chunks gehören zusammen RAID-10 (striped mirrors): mehrere chunks 38/43

40 Subvolumes Entspricht einem Posix-Dateisystem-Namespace Man kann gesamtes Volume mounten - und sieht alles oder nur subvolume - und sieht Teilbaum default-subvolume: Top level Volume 39/43

41 Sonstiges Copy on Write Verbesserung des Journal-Prinzips Änderungen werden zuerst als Kopie gespeichert dann Metadaten aktualisiert, die auf die neue Kopie zeigen Wenn es Metadaten für Metadaten gibt - selbes Prinzip Bsp. Super-Block Cloning: Atomare Erzeugung eines CoW snapshots einer Datei Snapshot: CoW eines subvolumes 40/43

42 Interna Basiert auf B-Bäumen Root-Tree enthält alles andere Bäume sind Objekte im root-tree File-System-Tree einer pro subvolume Verzeichnisse und Dateien inode items erweiterte Attribute, Access Control Lists Verzeichnis: enthält Verzeichnis-Item Hash statt Dateiname: nicht zum suchen geeignet Directory index item 41/43

43 Interna extents an sich außerhalb der Bäume wenn klein genug: in Baum mitgespeichert 4KB Defaultgröße Snapshots und CLones teilen sich extents Änderung eines Bereiches eines Clones > ev. drei neue extents geteilte extents vor bzw. nach der Änderung geändertes extent Bookend-extent: referenziert Teil eines anderen extent (all cow) extents in extent allocation tree verwaltet 42/43

44 btrfs-wald Log Tree: wie ein Journal um performance bei wiederholten cow/flush operationen nicht einbrechen zu lassen Checksum Tree enthält CRC-32C Prüfsummen für Daten und Metadaten Chunk and device Tree verwaltet Zuordnung der chunks zu devices logical chunk : physical chunk Data relocation tree Arbeitsbereich für temporäre extent-kopien 43/43