Dateisysteme

Hochleistungs-Ein-/Ausgabe

Michael Kuhn 2019-04-09

Wissenschaliches Rechnen Fachbereich Informatik Universität Hamburg Dateisysteme Orientierung Grundlagen Struktur Beispiel: Object Stores Datenstrukturen Leistungsbewertung Ausblick und Zusammenfassung

Michael Kuhn Dateisysteme 1/49 E/A-Schichten Orientierung

Anwendung

Bibliotheken

Paralleles verteiltes Dateisystem

Dateisystem Optimierungen Datenreduktion Leistungsanalyse Speichergerät/-verbund

Abbildung 1: E/A-Schichten und orthogonale Themen

Michael Kuhn Dateisysteme 2/49 Aufgabe Grundlagen

1. Strukturierung • Üblicherweise hierarchische Organisation • Auf Basis von Dateien und Verzeichnissen • Andere Ansätze: Tagging, Queries etc. 2. Verwaltung von Daten und Metadaten • Blockallokation und -verwaltung • Zugri über Datei- und Verzeichnisnamen • Zugrisrechte, Zeitstempel etc.

• Dateisysteme nutzen ein darunter liegendes Speichergerät • Kann auch durch Speicherverbund bereitgestellt werden • Logical Volume Manager (LVM) und/oder mdadm unter

Michael Kuhn Dateisysteme 3/49 Beispiele Grundlagen

• Linux: , ext4, XFS, , ZFS • Windows: FAT, exFAT, NTFS • OS X: HFS+, APFS • Universal: ISO9660, UDF • Pseudo: , proc

Michael Kuhn Dateisysteme 4/49 Beispiele... Grundlagen

• Netzwerk: NFS, AFS, Samba • Kryptographisch: EncFS, eCryptfs • Parallel verteilt: Spectrum Scale, , OrangeFS, CephFS, GlusterFS

• Setzen häufig auf darunterliegenden Dateisystemen auf

Michael Kuhn Dateisysteme 5/49 E/A-Schnittstellen Grundlagen

• Anfragen werden über E/A-Schnittstellen realisiert • Schnittstellen für unterschiedliche Abstraktionsebenen • Weiterleitung an das eigentliche Dateisystem • Low-Level-Funktionalität • POSIX, MPI-IO • High-Level-Funktionalität • HDF, NetCDF, ADIOS

Michael Kuhn Dateisysteme 6/49 E/A-Operationen Grundlagen

1 fd = open("/path/to/file", O_RDWR | O_CREAT | O_TRUNC, 2 S_IRUSR | S_IWUSR); 3 rv = close(fd); 4 rv = unlink("/path/to/file");

Listing 1: E/A über POSIX-Funktionen

• Mit open können auch Dateien erstellt werden • Viele mögliche Flags und Modi • Initialer Zugri über Pfad • Danach über File Descriptor (bis auf einige Ausnahmen) • Alle Funktionen liefern einen Rückgabewert • Bei Fehlern sollte errno überprü werden

Michael Kuhn Dateisysteme 7/49 E/A-Operationen... Grundlagen

1 nb = write(fd, data, sizeof(data));

Listing 2: E/A über POSIX-Funktionen

• write liefert die Anzahl der geschriebenen Bytes zurück • Muss nicht notwendigerweise der übergebenen Größe entsprechen (Fehlerbehandlung!) • write verändert intern den Dateizeiger (alternativ: pwrite) • Funktionen befinden sich in der libc • Diese führt System Calls durch

Michael Kuhn Dateisysteme 8/49 VFS Grundlagen

• Virtual (Switch) • Zentrale Dateisystemkomponente im Kernel • Standardisiertes Interface für alle Dateisysteme (POSIX) • Gibt Dateisystemstruktur und -schnittstelle größtenteils vor • Leitet Anfragen der Anwendungen an das entsprechende Dateisystem weiter • Basierend auf dem Mountpoint • Ermöglicht die Unterstützung unterschiedlichster Dateisysteme • Anwendungen bleiben durch POSIX trotzdem portabel

Michael Kuhn Dateisysteme 9/49 VFS... [3] Grundlagen

mmap (anonymous pages) Applications (processes) malloc ... stat(2) open(2) read(2) write(2) (2) VFS Block-based FS Network FS Pseudo FS Special ext4 NFS purpose FS Direct I/O proc sysfs Page btrfs ifs iso9660 smbfs ... (O_DIRECT) pipefs futexfs tmpfs ramfs cache gfs ocfs ... usbfs ... devtmpfs Stackable FS

FUSE

userspace (e.g. ) network

stackable (optional) struct bio - sector on disk BIOs (block I/Os) Devices on top of “normal” BIOs (block I/Os) - sector cnt block devices - bio_vec cnt drbd LVM - bio_vec index device mapper mdraid - bio_vec list dm-crypt dm-mirror ... dm-cache dm-thin bcache dm-raid dm-delay

The Linux Storage Stack Diagram http://www.thomas-krenn.com/en/wiki/Linux_Storage_Stack_Diagram Created by Werner Fischer and Georg Schönberger License: CC-BY-SA 3.0, see http://creativecommons.org/licenses/by-sa/3.0/ Michael Kuhn Dateisysteme 10 / 49 VFS... [3] Grundlagen

The Linux Storage Stack Diagram

version 4.10, 2017-03-10 outlines the Linux storage stack as of Kernel version 4.10 Virtual Host FireWire Fibre Channel over Ethernet ISCSI Fibre Channel USB mmap (anonymous pages) Applications (processes) LIO malloc vfs_writev, vfs_readv, ...... stat(2) open(2) read(2) write(2) chmod(2) VFS tcm_fc sbp_target tcm_usb_gadget tcm_vhost tcm_qla2xxx iscsi_target_mod Block-based FS Network FS Pseudo FS Special ext2 ext3 ext4 xfs NFS coda proc purpose FS target_core_mod Direct I/O sysfs Page btrfs ifs iso9660 smbfs ... (O_DIRECT) pipefs futexfs tmpfs ramfs cache target_core_file gfs ocfs ... ceph usbfs ... devtmpfs Stackable FS

target_core_iblock ecryptfs overlayfs unionfs FUSE

userspace (e.g. sshfs) target_core_pscsi target_core_user network

stackable (optional) struct bio - sector on disk BIOs (block I/Os) Devices on top of “normal” BIOs (block I/Os) - sector cnt block devices - bio_vec cnt drbd LVM - bio_vec index device mapper mdraid - bio_vec list dm-crypt dm-mirror ... dm-cache dm-thin bcache dm-raid dm-delay userspace

BIOs BIOs Block Layer BIOs

I/O scheduler blkmq Maps BIOs to requests multi queue hooked in device drivers noop Software (they hook in like stacked cfq ... queues devices do) deadline

Hardware Hardware dispatch ... dispatch queue queues

Request Request BIO based drivers based drivers based drivers

Request-based device mapper targets dm-multipath SCSI mid layer sysfs scsi-mq /dev/zram* /dev/rbd* /dev/mmcblk*p* /dev/nullb* /dev/vd* /dev/rssd* /dev/skd* (transport attributes) SCSI upper level drivers /dev/sda /dev/sd* ... /dev/ubiblock* /dev/nbd* /dev/loop* /dev/nvme*n* /dev/rsxx* Transport classes scsi_transport_fc /dev/sr* /dev/st* zram ubi rbd nbd mmc loop null_blk virtio_blk mtip32xx nvme skd rsxx scsi_transport_sas scsi_transport_... network memory SCSI low level drivers libata megaraid_sas qla2xxx pm8001 iscsi_tcp virtio_scsi ufs ...

ahci ata_piix ... aacraid lpfc mpt3sas vmw_pvscsi

network

HDD SSD DVD LSI Qlogic PMC-Sierra para-virtualized Micron nvme stec virtio_pci mobile device drive RAID HBA HBA SCSI flash memory PCIe card device device Adaptec Emulex LSI 12Gbs VMware's SD-/MMC-Card RAID HBA SAS HBA para-virtualized IBM flash Physical devices SCSI adapter

The Linux Storage Stack Diagram http://www.thomas-krenn.com/en/wiki/Linux_Storage_Stack_Diagram Created by Werner Fischer and Georg Schönberger License: CC-BY-SA 3.0, see http://creativecommons.org/licenses/by-sa/3.0/ Michael Kuhn Dateisysteme 11 / 49 Dateisystemobjekte Struktur

• Unterscheidung in Benutzer- und Systemsicht • Benutzer sehen Dateien und Verzeichnisse mit Metadaten • Dateien bestehen aus Bytes, Verzeichnisse enthalten Dateien und Verzeichnisse • Das System verwaltet Interna • Fasst mehrere Blöcke zu Dateien zusammen etc.

• Inodes • Eigentliche Basisobjekte des Dateisystems • Jeder Datei und jedem Verzeichnis ist ein Inode zugeordnet (siehe stat) • Enthalten Metadaten • Sowohl für Benutzer sichtbare als auch interne • Üblicherweise eindeutige IDs und fixe Größe

Michael Kuhn Dateisysteme 12 / 49 Dateisystemobjekte... Struktur

• Dateien • Enthalten Daten in Form eines Byte-Arrays • POSIX macht keine weitergehenden Vorgaben • Können gelesen/geschrieben werden (explizit) • Können in den Speicher gemappt werden (implizit) • Verzeichnisse • Zur Organisation des Namensraumes • Können Dateien und weitere Verzeichnisse enthalten • Aus Benutzersicht eine Liste • Intern häufig Baumstrukturen

Michael Kuhn Dateisysteme 13 / 49 Dateien Struktur

1 nb = pwrite(fd, data, sizeof(data), 42); 2 nb = pread(fd, data, sizeof(data), 42);

Listing 3: Expliziter Zugri

• pwrite und pread verhalten sich wie write bzw. read • Explizite Angabe des Osets und damit threadsicher • Zugri über File Descriptor • Kann von mehreren Threads parallel genutzt werden

Michael Kuhn Dateisysteme 14 / 49 Dateien... Struktur

1 char* pt = mmap(NULL, file_size, PROT_READ | PROT_WRITE, 2 MAP_SHARED, fd, offset); 3 memcpy(pt + 42, data, sizeof(data)); 4 memcpy(data, pt + 42, sizeof(data)); 5 munmap(pt, FILE_SIZE);

Listing 4: Impliziter Zugri

• mmap erlaubt es eine Datei in den Speicher einzublenden • Datei wird an Adresse pt eingeblendet • Verschiedene Sichtbarkeitseinstellungen (shared vs. private) • Zugri wie auf andere Speicherobjekte • Z. B. via memcpy oder direkte Zuweisung

Michael Kuhn Dateisysteme 15 / 49 Dateien... Struktur

• Beide Zugrisarten haben jeweils Vor- und Nachteile • Beide Modi profitieren vom Caching durch das Betriebssystem • Expliziter Zugri • Vorteile: genaue Kontrolle über E/A, Möglichkeit direkter E/A • Nachteile: separate Puer notwendig, Kopiervorgänge zwischen Kernel- und Userspace • Impliziter Zugri • Vorteile: keine separaten Puer notwendig, eiziente E/A durch das Betriebssystem, keine unnötigen Kopiervorgänge, große Dateien können komplett gemappt werden • Nachteile: keine genaue Kontrolle, kompliziertere Fehlerbehandlung (Signale)

Michael Kuhn Dateisysteme 16 / 49 Verzeichnisse Struktur

Inode Größe Namenslänge Dateityp Name 23 10 2 2 . 24 11 3 2 ...... 42 14 6 1 hello 42 14 6 1 world Abbildung 2: ext4-Verzeichniseintrag [1]

• Traditionell lineares Array • Langsam, da über das komplette Array iteriert werden muss • Heutzutage eher Baumstrukturen • Deutlich komplexer, dafür geringere Zugriszeiten • Name wird nicht im Inode gespeichert • Mehrere Namen können auf denselben Inode zeigen Michael Kuhn Dateisysteme 17 / 49 Inodes Struktur

Feldgröße Inhalt 2 Bytes Berechtigungen 2 Bytes Benutzer-ID 4 Bytes Dateigröße 4 Bytes Zugriszeit 4 Bytes Inode-Änderungszeit 4 Bytes Datenänderungszeit 4 Bytes Löschzeit 2 Bytes Gruppen-ID 2 Bytes Linkzahl . . . . 60 Bytes Blockzeiger, -Baum oder Inline-Daten . . . . 4 Bytes Versionsnummer 100 Bytes Freier Speicher Abbildung 3: ext4-Inode (256 Bytes) [1] Michael Kuhn Dateisysteme 18 / 49 Inodes... Struktur

• Kompliziert durch Rückwärtskompatibilität • On-Disk-Format kann nur schwer geändert werden • Viele Felder sind aus Kompatibilitätsgründen aufgeteilt • Zeitstempel: 4 Bytes für Sekunden seit 1970, 4 Bytes für Nanosekundenauflösung • Größe: Obere und untere 4 Bytes • Felder mehrfach überladen • Blockzeiger, Extent-Baum oder Inline-Daten (falls Datei kleiner als 60 Bytes) • 100 Bytes am Inode-Ende für erweiterte Attribute

Michael Kuhn Dateisysteme 19 / 49 Inodes... Struktur

1 $ touch foo 2 $ ls -l foo 3 -rw-r--r--. 1 user group 0 19. Apr 18:48 foo 4 $ ln foo bar 5 $ ls -l foo bar 6 -rw-r--r--. 2 user group 0 19. Apr 18:48 bar 7 -rw-r--r--. 2 user group 0 19. Apr 18:48 foo 8 $ stat --format=%i foo bar 9 641174 10 641174 11 $ rm foo 12 $ ls -l bar 13 -rw-r--r--. 1 user group 0 19. Apr 18:48 bar

Listing 5: Inode vs. Datei

Michael Kuhn Dateisysteme 20 / 49 POSIX-Schnittstelle Struktur

• Syntax beschreibt verfügbare Operationen und deren Parameter • open, close, creat • read, write, lseek • chmod, chown, stat • link, unlink • (f)truncate, fallocate • Semantik spezifiziert wie sich E/A-Operationen verhalten sollen • write: “POSIX requires that a read(2) which can be proved to occur aer a write() has returned returns the new data. Note that not all filesystems are POSIX conforming.”

Michael Kuhn Dateisysteme 21 / 49 Sparse-Dateien und Preallokation Struktur

• Sparse-Dateien: Dateien mit „Löchern“ • Z. B. mit lseek oder truncate • Eiziente Speicherung von Dateien mit vielen 0-Bytes

1 $ truncate --size=1G dummy 2 $ ls -lh dummy 3 -rw-r--r--. 1 user group 1,0G 18. Apr 23:49 dummy 4 $ du -h dummy 5 0 dummy

Listing 6: Erzeugung einer Sparse-Datei

Michael Kuhn Dateisysteme 22 / 49 Sparse-Dateien und Preallokation... Struktur

• Preallokation: Speicher vorallokieren • Mit fallocate bzw. posix_fallocate • Verhindert Fragmentierung bei vielen Dateivergrößerungen

1 $ fallocate --length $((1024 * 1024 * 1024)) dummy 2 $ ls -lh dummy 3 -rw-r--r--. 1 user group 1,0G 19. Apr 19:14 dummy 4 $ du -h dummy 5 1,0G dummy

Listing 7: Preallokation einer Datei

Michael Kuhn Dateisysteme 23 / 49 ext4 Beispiel: ext4

• Standard-Dateisystem in vielen Linux-Distributionen • Eingeführt 2006, stabil 2008 • Vorgänger: ext, ext2, ext3 • Statische Festlegung diverser Parameter bei Dateisystemerzeugung • Blockgröße, Dateisystemgröße, Inode-Zahl etc. • Einige können nachträglich angepasst werden • Traditionelles Dateisystem • Daten werden direkt geändert (kein Copy on Write) • Keine Prüfsummen für Daten und Schnappschüsse • Keine sonstigen Komfortfunktionen

Michael Kuhn Dateisysteme 24 / 49 ext Beispiel: ext4

• Erstes Dateisystem speziell für Linux • Nutzte als erstes Dateisystem die VFS-Schicht • Inspiriert vom (UFS) • Beseitigte Beschränkungen des MINIX-Dateisystems • Dateigrößen bis 2 GB • Dateinamen bis 255 Zeichen

Michael Kuhn Dateisysteme 25 / 49 ext2 Beispiel: ext4

• Separate Zeitstempel für Zugri und Inode-/Datenänderung • Datenstrukturen für zukünige Erweiterungen ausgelegt • Testumgebung für neue VFS-Funktionen • Access Control Lists (ACLs) • Erweiterte Attribute

Michael Kuhn Dateisysteme 26 / 49 ext3 Beispiel: ext4

• Journaling • Erklärung folgt später • Dateisystemvergrößerung zur Laufzeit • Nützlich für LVM-Umgebungen • H-Baum für größere Verzeichnisse • Verkürzt die Suchzeiten im Verzeichnis

Michael Kuhn Dateisysteme 27 / 49 ext4 Beispiel: ext4

• Größere Dateisysteme, Dateien und Verzeichnisse • Extents • Preallokation, verzögerte Allokation und verbesserte Multiblockallokation • Journal-Prüfsummen • Schnellere Dateisystemüberprüfung • Nanosekunden-Zeitstempel • Unterstützung für TRIM

Michael Kuhn Dateisysteme 28 / 49 ext4... Beispiel: ext4

Inhalt Größe Padding (Blockgruppe 0) 1.024 Bytes Superblock 1 Block Gruppenbeschreibung m Blöcke Reservierte GDT-Blöcke n Blöcke Daten-Bitmap 1 Block Inode-Bitmap 1 Block Inode-Tabelle k Blöcke Datenblöcke l Blöcke Abbildung 4: ext4-Blockgruppe [1]

• Das Speichergerät ist in mehrere Blockgruppen unterteilt • Flexible Blockgruppen fassen mehrere Blockgruppen zusammen • Blockgröße bestimmt Anzahl an Inodes und Datenblöcken pro Blockgruppe Michael Kuhn Dateisysteme 29 / 49 ext4... Beispiel: ext4

Blockgröße 1 KiB 2 KiB 4 KiB 64 KiB Blöcke 264 264 264 264 Inodes 232 232 232 232 Dateisystemgröße 16 ZiB 32 ZiB 64 ZiB 1 YiB Dateigröße (Extents) 4 TiB 8 TiB 16 TiB 256 TiB Dateigröße (Blöcke) 16 GiB 256 GiB 4 TiB 256 PiB Abbildung 5: ext4-Limits im 64-Bit-Modus [1]

• Standardgröße ist 4 KiB (und oizielles Maximum) • Sollte nicht größer als Seitengröße gewählt werden • Unterschiedliche maximale Dateigrößen für Extents und Blöcke

Michael Kuhn Dateisysteme 30 / 49 Allokation Beispiel: ext4

1. Blockbasiert • Viele Blöcke gleicher Größe (üblicherweise 4 KiB) • Zeiger auf Blöcke im Inode • Direkt, indirekt, doppelt indirekt, dreifach indirekt • Hoher Overhead bei großen Dateien • Beispiel: 1 TiB große Datei benötigt 268.435.456 Zeiger • Beschränkt maximale Dateigröße

Michael Kuhn Dateisysteme 31 / 49 Allokation... [2] Beispiel: ext4

Michael Kuhn Dateisysteme 32 / 49 Allokation... Beispiel: ext4

2. Extentbasiert • Wenige möglichst große Extents • Vier Extents können im Inode gespeichert werden • Mehr in einer Baumstruktur und zusätzlichen Blöcken • Zeiger auf Startblock und Länge • Maximale Länge: 32.768 Blöcke • Entspricht 128 MiB bei einer Blockgröße von 4 KiB • Ermöglicht größere Dateien bei üblichen Blockgrößeren

Michael Kuhn Dateisysteme 33 / 49 Allokation... Beispiel: ext4

• Blockallokation • Versuche zusammenhängende Blöcke zu allokieren • Versuche Blöcke in derselben Blockgruppe zu allokieren • Multiblockallokation • Spekulativ 8 KiB bei Dateierzeugung allokieren • Verzögerte Allokation • Blöcke werden erst allokiert, wenn auf das Speichergerät geschrieben werden muss

Michael Kuhn Dateisysteme 34 / 49 Allokation... Beispiel: ext4

• Dateien und Verzeichnisse • Blöcke möglichst in der Blockgruppe des Inodes allokieren • Dateien möglichst in der Blockgruppe des Verzeichnisses allokieren

• Ziele der Allokationsstrategien • Möglichst große Zugrie • Festplatten erreichen nur geringe IOPS-Werte • Zugrie nahe beieinander • Reduziert Kopfbewegungen bei Festplatten • Metadaten der Blockgruppe eventuell schon im Cache • Optimierungen bei SSDs weniger von Bedeutung

Michael Kuhn Dateisysteme 35 / 49 Journaling Beispiel: ext4

• Problem: Dateisystemoperationen benötigen mehrere Schritte • Z. B. das Löschen einer Datei 1. Entfernen des Verzeichniseintrags 2. Freigeben des Inodes 3. Freigeben der Datenblöcke • Problematisch im Fall eines Absturzes • Journaling zur Sicherung der Konsistenz des Dateisystems

Michael Kuhn Dateisysteme 36 / 49 Journaling... Beispiel: ext4

• Geplante Änderungen werden ins Journal eingetragen • Entfernen wenn Operation vollständig durchgeführt • Prüfung bei anschließender Dateisystemüberprüfung • Änderungen werden wiederholt oder verworfen • Unterschiedliche Modi • Metadaten-Journaling und volles Journaling

Michael Kuhn Dateisysteme 37 / 49 Journaling... Beispiel: ext4

• Journal: Alle Änderungen werden ins Journal geschrieben • Deaktiviert verzögerte Allokation und O_DIRECT • Ordered: Metadaten werden ins Journal geschrieben • Zugehörige Daten werden vor Metadaten geschrieben • Problematisch mit verzögerter Allokation • Ist die Standardeinstellung • Writeback: Metadaten werden ins Journal geschrieben • Bietet höchste Leistung aber geringste Sicherheit

Michael Kuhn Dateisysteme 38 / 49 Funktionen Object Stores

• „Dateisystem Light“ • Dünne Abstraktionsschicht über Speichergeräten • Objektbasierter Zugri auf Daten • Nur Grundoperationen • Erstellen, Önen, Schließen, Lesen, Schreiben • Manchmal nur Lesen bzw. Schreiben gesamter Objekte möglich • Mögliche Unterstützung für Object Sets • Können benutzt werden um verwandte Objekte zu gruppieren

Michael Kuhn Dateisysteme 39 / 49 Funktionen... Object Stores

• Üblicherweise keine Pfade • Zugri über eindeutige IDs • Kein Overhead durch Pfadauflösung • Dadurch auch flacher Namensraum • Block-/Extent-Allokation • Einer der komplexesten und leistungsrelevantesten Aspekte • Auf unterschiedlichen Abstraktionsebenen verfügbar • Festplatte, Dateisysteme, Cloudspeicher

Michael Kuhn Dateisysteme 40 / 49 Schichtung Object Stores

• Können als Unterbau für Dateisysteme genutzt werden • Erlaubt Konzentration auf Dateisystemfunktionalität • Speicherverwaltung durch separate Schicht • Bei lokalen Dateisystemen häufig nicht sinnvoll • Funktionalität größtenteils durch POSIX vorgegeben • Hauptunterschied ist Blockallokation • Sehr sinnvoll für parallele verteilte Dateisysteme • Kein redundanter Dateisystem-Overhead

Michael Kuhn Dateisysteme 41 / 49 B-Baum vs. B+-Baum Datenstrukturen

7 16

1 2 5 6 9 12 18 21

Abbildung 6: B-Baum [4]

• Verallgemeinerter Binärbaum • Optimiert für Systeme, die große Blöcke lesen/schreiben • Zeiger und Daten gemischt

Michael Kuhn Dateisysteme 42 / 49 B-Baum vs. B+-Baum... Datenstrukturen

7 16

1 2 5 6 7 9 12 16 18 21

Abbildung 7: B+-Baum [4]

• Daten nur in Blättern • Vorteilha für Caching, da alle Knoten einfacher zu cachen sind • Benutzt in NTFS, XFS etc.

Michael Kuhn Dateisysteme 43 / 49 Alternativen Datenstrukturen

• H-Baum • Basiert auf B-Baum • Andere Behandlung von Hash-Kollisionen • Benutzt in ext3 und ext4 • Bε-Baum • Optimiert für Schreibvorgänge • Verbesserte Leistung für Einfügeoperationen, Bereichsabfragen und Aktualisierungen

Michael Kuhn Dateisysteme 44 / 49 Leistungsbewertung Leistungsbewertung

• Dateisystemleistung ist schwierig zu bewerten • Viele unterschiedliche Faktoren • Daten- vs. Metadatenleistung • Leistung unterschiedlicher Funktionen und Zugrismuster • Leistung für spezifische Anforderungen messen • Datensicherheit kostet üblicherweise Leistung • Volles Journaling, Prüfsummen etc.

Michael Kuhn Dateisysteme 45 / 49 Kernel- vs. Userspace Leistungsbewertung

• Dateisysteme üblicherweise direkt im Kernel implementiert • Hoher Wartungsaufwand • Komplexere Implementierung • Alternative: (FUSE) • Besteht aus Kernelmodul und Bibliothek • Entwicklung von Dateisystemen als normale Prozesse • Umleitung in Userspace durch VFS und FUSE-Modul • Geringere Leistung durch Kontextwechsel

Michael Kuhn Dateisysteme 46 / 49 Kernel- vs. Userspace... [5] Leistungsbewertung

./hello /tmp/fuse

ls -l /tmp/fuse libfuse

glibc glibc Userspace

Kernel FUSE

NFS VFS Ext3

...

Michael Kuhn Dateisysteme 47 / 49 Ausblick Ausblick und Zusammenfassung

• Lokale Dateisysteme sind häufig Basis für parallele verteilte Dateisysteme • Existierende und optimierte Blockallokation etc. • Object Stores wären häufig besser geeignet • Moderne Dateisysteme integrieren zusätzliche Funktionen • Volumenverwaltung, Prüfsummen, Schnappschüsse etc. • Komfort und Datensicherheit zunehmend wichtig

Michael Kuhn Dateisysteme 48 / 49 Zusammenfassung Ausblick und Zusammenfassung

• Dateisysteme organisieren Daten und Metadaten • Üblicherweise standardisierte Schnittstelle • Hauptobjekte sind Dateien und Verzeichnisse • Inodes speichern Metadaten • Neue Techniken zur Eizienzsteigerung • Journaling um Konsistenz sicherzustellen • Speicherallokation mit Hilfe von Extents • Baumstrukturen für skalierbaren Zugri

Michael Kuhn Dateisysteme 49 / 49 Quellen

[1] djwong. Ext4 Disk Layout. https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout. [2] Hal Pomeranz. Understanding Indirect Blocks in Unix File Systems. http://digital-forensics.sans.org/blog/2008/12/24/ understanding-indirect-blocks-in-unix-file-systems. [3] Werner Fischer and Georg Schönberger. Linux Storage Stack Diagramm. https://www.thomas-krenn.com/de/wiki/Linux_Storage_Stack_ Diagramm. [4] Wikipedia. B-tree. http://en.wikipedia.org/wiki/B-tree. [5] Wikipedia. Filesystem in Userspace. http://en.wikipedia.org/wiki/Filesystem_in_Userspace.