Dateisysteme
Hochleistungs-Ein-/Ausgabe
Michael Kuhn 2019-04-09
Wissenschaliches Rechnen Fachbereich Informatik Universität Hamburg Dateisysteme Orientierung Grundlagen Struktur Beispiel: ext4 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 Linux
Michael Kuhn Dateisysteme 3/49 Beispiele Grundlagen
• Linux: tmpfs, ext4, XFS, btrfs, ZFS • Windows: FAT, exFAT, NTFS • OS X: HFS+, APFS • Universal: ISO9660, UDF • Pseudo: sysfs, proc
Michael Kuhn Dateisysteme 4/49 Beispiele... Grundlagen
• Netzwerk: NFS, AFS, Samba • Kryptographisch: EncFS, eCryptfs • Parallel verteilt: Spectrum Scale, Lustre, 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 File System (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) chmod(2) VFS Block-based FS Network FS Pseudo FS Special ext2 ext3 ext4 xfs NFS coda purpose FS Direct I/O proc sysfs Page btrfs ifs iso9660 smbfs ... (O_DIRECT) pipefs futexfs tmpfs ramfs cache gfs ocfs ... ceph usbfs ... devtmpfs Stackable FS
ecryptfs overlayfs unionfs FUSE
userspace (e.g. sshfs) 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, Extent-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 Unix File System (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: Filesystem in Userspace (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.