SSD-basiertes Caching einer Festplatte auf Dateisystemebene DIPLOMARBEIT

Transkript

1 SSD-basiertes Caching einer Festplatte auf Dateisystemebene DIPLOMARBEIT Betreut von Dr. Jan Richling, Anselm Busse 29. Dezember 2011 Sebastian Pipping

2

3 Die selbständige und eigenhändige Ausfertigung versichert an Eides statt Berlin, den Sebastian Pipping

4

5 Danksagung Bedanken möchte ich mich für die exzellente Betreung und den Zugriff auf einen eigenen Raum sowie einen Computer mit Solid-State-Drive bei Dr. Jan Richling und Anselm Busse, für die Möglichkeit, mich auf diese Diplomarbeit konzentrieren zu können, statt parallel arbeiten zu müssen, bei meinen Eltern Dr. Heike Pipping und Rainer Pipping und für Ideen und Anregungen bei Tobias Tünnermann, Kai Dietrich, Sebastian Lohff, Katarina Schulz, Peter Stuge und meinem Bruder Elias Pipping. Danke! 3

6

7 Abstract Die vorliegende Arbeit beschäftigt sich mit der Idee, den Zugriff auf eine Festplatte durch Einführung eines persistenten Cache zu beschleunigen. Als Speichermedium wird ein Solid-State-Drive verwendet, ein Medium mit höherer Performanz aber weniger Speicherplatz als üblich für eine aktuelle Festplatte. Das Caching setzt hierbei nicht auf Ebene des Blockgerätes an, sondern arbeitet auf Ebene des Dateisystems. Vorgestellt wird das Konzept und die prototypische Implementierung eines Caching-Dateisystems, bei dem die ersten k Byte jeder Datei auf dem Solid-State-Drive vorgehalten werden. Verschiedene statische und dynamische Ansätze zur Wahl von k werden aufgezeigt und evaluiert. headcachefs, eine Implementierung dieses Konzeptes, wird in der vorliegenden Arbeit im Detail vorgestellt und evaluiert. Diese Implementierung basiert auf FUSE, einem Framework zur Entwicklung von Dateisystemen im User space. 5

8

9 Inhaltsverzeichnis Abstract 5 Inhaltsverzeichnis 7 Abbildungsverzeichnis 11 Glossar 13 1 Einführung Speichermedien von heute Festplatten (HDDs) Solid-State-Drives (SSDs) Vergleich zwischen HDDs und SSDs Problemstellung 23 3 Grundlagen FUSE Stackable file systems Umsetzung im User space Vorhandene Ansätze SSD-basiertes Caching von Blockgeräten SSD-basiertes Caching von Dateien FS-Cache mcachefs CacheFS

10 INHALTSVERZEICHNIS Conquest xcachefs Zusammenfassung Ansatz Unzulänglichkeiten vorhandener Ansätze Einschränkungen auf Blockgeräteebene Ungünstige Entscheidungen auf Dateisystemebene Ansatz dieser Arbeit Grenz-Algorithmen Algorithmus fixed Fall Null Fall unbeschränkt Fall optimal Algorithmus equalshare Algorithmus aimfull Dateigrößen-basierte Algorithmen Inhalts-basierte Algorithmen Design Überblick Funktionsweise Erwägungen Schreibfehler Paralleles Lesen und Schreiben Inkonsistenzen durch Multi-Threading Caching von Metadaten Integration des Kernel page cache Ausschluss von Direct I/O Speicherverbrauch nicht-regulärer Dateien Sicherheit Zugriffsrechte Implementierung headcachefs Merkmale Herausforderungen Anzahl gleichzeitig geöffneter Dateien Endianness

11 INHALTSVERZEICHNIS Erweiterte Dateisystem-Attribute (xattr) Regelmäßige, interne Aufrufe von fstat Einschränkungen Zeitstempel atime FSCK Evaluierungs-Prozess Aufnahme Umgebung Testlauf Wiedergabe Evaluierung Performanz von FUSE Aufbau Ergebnisse Ergebnisse Erschwernisse Einschränkungen Test-System Vergleich der Grenz-Algorithmen Fallunterscheidung Algorithmus fixed Einfluss einzelner Optionen Zusammenfassung und Ausblick 83 Literaturverzeichnis 85 A Skriptgesteuerte Installation 89 B recordfs 93 9

12

13 Abbildungsverzeichnis 1.1 Speicher-Hierarchie Aufbau einer Festplatte Architektur von FUSE Stackable file system UnionFS Grenz-Algorithmus equalshare Grenz-Algorithmus aimfull Überblick Architektur headcachefs Replikation von Dateisystem-Einträgen in headcachefs Inkonsistenz durch fehlende Synchronisation Mehraufwand durch Caching von Metadaten Aufbau Protokollierung NFS-Root Aufbau Protokollierung chroot Lese-Performanz von FUSE auf ext Schreib-Performanz von FUSE auf ext Lese-Performanz von FUSE auf XFS Schreib-Performanz von FUSE auf XFS Vergleich Grenz-Algorithmen: Laufzeiten Vergleich Grenz-Algorithmen: Transfer-Volumina Vergleich Grenz-Algorithmen: Nutzung Speicher SSD Vergleich fester Grenzen: Laufzeiten Vergleich fester Grenzen: Transfer-Volumina Vergleich fester Grenzen: Nutzung Speicher SSD

14 Abbildungsverzeichnis 8.11 Einfluss einzelner Optionen: Laufzeiten

15 Glossar Bind-Mount Mounten mit Option bind; dynamischer Ansatz für Hardlinks auf Ordner Blockgerät Hardware, die vom Linux-Kernel als Byte-Container behandelt wird btrfs B-tree file system; Teil des Linux-Kernels chroot-umgebung Shell mit abweichendem Root-Verzeichnis Community Gruppe von Menschen mit vergleichbaren Werten oder Zielen DRAM Dynamic random-access memory ecryptfs Verschlüsselungs-Dienst implementiert als Stackable file system; Teil des Linux-Kernels ELF Executable and Linking Format (nach TIS Committee (1995)) ext4 Extended file system Version 4; Teil des Linux-Kernels File descriptor Zugriffsnummer einer geöffneten Datei, bezogen auf einen bestimmten Prozess Inode Container für Metadaten einer Datei Hardlink fester Alias für eine Datei; eine Datei und ein (weiterer) Hardlink auf diese Datei sind nicht unterscheidbar. HDD Hard disk drive; Festplatte 13

16 Abbildungsverzeichnis headcachefs SSD-basiertes Caching-Dateisystem; Prototyp des in der vorliegenden Arbeit verfolgten Ansatzes hookfs FUSE-basiertes Stackable file system, das lediglich Anfragen weiterleitet; entstanden als Teil der vorliegenden Arbeit Kernel space Gegenstück zu User space; virtueller Speicher, der nicht zu Prozessen außerhalb des Kernels gehört Mounten Einhängen von Dateisystemen in den Verzeichnis-Baum Mutex Schloss-Variable; verwendet zur Realisierung von kritischen Abschnitten (Mutual exclusion) Named pipe Baustein für Inter-Prozess-Kommunikation mit Repräsentation im Dateisystem NFS Network File System Offset Abstand zum Anfang der Datei Page cache Cache des Linux-Kernels, der für Seiten/Blöcke von Blockgeräten und Dateisystemen verwendet wird POSIX Portable operating system interface; ein Betriebssystemstandard Regulärer Ausdruck Syntax zur Definition einer Menge von Zeichenketten RAM Random access memory; Arbeitsspeicher recordfs Werkzeug zur Protokollierung auf Dateisystemebene; entstanden als Teil der vorliegenden Arbeit (Anhang B, Seite 93) Rollback Zurücksetzen von Daten in einen vorherigen, konsistenten Zustand Root-Rechte unbeschränkte Zugriffsrechte; Rechte des Nutzers root Setuid-Bit bewirkt beim Starten eines Programmes den Wechsel der Nutzer-Rechte auf die Rechte des Eigentümers der Datei Shell Programm mit Kommandozeilen-Interface Shell-Code Programm, das eine Shell startet 14

17 Abbildungsverzeichnis SSD Solid-State-Drive; neuartiges, nicht-flüchtiges Speichermedium Stackable file system siehe Sektion 3.2 auf Seite 28 Symlink spezielle Datei, die keine Daten, sondern den Ort einer anderen Datei beinhaltet Thread leichtgewichtiger Prozess; ein Prozess besteht aus einem oder mehreren Threads. tmpfs temporäres Dateisystem basierend auf Arbeitsspeicher an Stelle eines Blockgerätes User Experience Erlebnis/Erfahrung eines menschlichen Anwenders bei Nutzung einer Software User space Gegenstück zu Kernel space; virtueller Speicher, der zu Prozessen außerhalb des Kernels gehört VFS virtual file system; virtuelles Dateisystem Write-Back-Cache Caching-Ansatz bei dem Schreib-Anfragen verzögert an das gecachete Medium weitergeleitet werden Write-Through-Cache Caching-Ansatz bei dem Schreib-Anfragen direkt an das gecachete Medium weitergeleitet werden XFS XFS file system; Teil des Linux-Kernels 15

18

19 Kapitel 1 Einführung Dieses Kapitel gibt einen Überblick über die aktuelle Situation der Speichermedien und geht dann näher auf Festplatten und Solid-State-Drives im Speziellen ein. In Kapitel 2 wird die Problemstellung definiert. Kapitel 3 vermittelt Wissen, das in folgenden Teilen dieser Arbeit vorausgesetzt wird. In Kapitel 4 werden existierende Ansätze vorgestellt, verglichen und bewertet. Kapitel 5 beschreibt den Ansatz, der in dieser Arbeit untersucht wird, wie die beiden Speichermedien zusammenarbeiten und wie Daten verteilt werden. Kapitel 6 ist dem Design des implementierten Prototyps headcachefs gewidmet: den Fragen, Problemen und Konsequenzen, die der gewählte Ansatz mit sich bringt. Kapitel 7 stellt verschiedene Eigenschaften der konkreten Implementierung headcachefs vor. Es zeigt auf, welche Einschränkungen nötig waren und welche Herausforderungen bestanden. In Kapitel 8 wird headcachefs evaluiert, es werden Messergebnisse vorgestellt und interpretiert. Kapitel 9 schließlich zieht Resümee und zeigt auf, welche Potentiale ununtersucht geblieben sind. 17

20 KAPITEL 1. EINFÜHRUNG 1.1 Speichermedien von heute Nach Busse (2010) folgen Prozessoren dem Mooreschen Gesetz, das besagt, dass sich die Leistung von Prozessoren alle 18 Monate verdoppelt. Die Entwicklung der Speichertechnik habe nach Busse mit diesem Wachstum aber nicht mithalten können. Dies führe dazu, dass dem Prozessor zu verarbeitende Daten nicht schnell genug zur Verfügung gestellt werden können. Folglich besteht das Potential, durch Performanz-Steigerungen auf der Ebene des Datenspeichers auch Gewinne für die Performanz des Gesamtsystems zu erzielen. Um die zeitliche und räumlich Lokalität von Programmen das wiederholten Lesen derselben Daten beziehungsweise das Lesen von Daten in unmittelbarer Umgebung auszunutzen, werden auf mehreren Ebenen Kopien von Daten in schnelleren, aber kleineren Zwischenspeichern sogenanntem Cache vorgehalten: so wird zum Beispiel ein Teil des Arbeitsspeichers vom Betriebssystem genutzt, um Daten der Festplatte zwischen zu speichern. Hinzu kommt ein ökonomischer Faktor, der für die Verwendung von Cache spricht: Die Herstellung von einem Gigabyte Level-2-Cache ist kostspieliger als die Herstellung eines Gigabytes Arbeitsspeicher. Diese Hierarchie betrifft die vier Eigenschaften Preis pro Byte, Kapazität, Zugriffszeit und Datendurchsatz. Mit sinkender Zugriffszeit erhöht sich der Datendurchsatz, steigt der Preis pro Byte und verringert sich die Kapazität. Abbildung 1.1 visualisiert diesen Zusammenhang und vereint die Sichtweisen aus Busse (2010) und Garcia-Molina u. a. (2001). 18

21 KAPITEL 1. EINFÜHRUNG flüchtig nicht flüchtig Preis pro Byte Datendurchsatz Softwareverwaltet CPU- Register Level-1-Cache Level-2-Cache Arbeitsspeicher Solid-State Drives Festplatten Tertiäre Speichermedien Zugriffszeit Kapazität Hardwareverwaltet Abbildung 1.1: Speicher-Hierarchie Erst seit kurzem steht eine Technologie namens Solid-State-Drive zur Verfügung, die in der Speicher-Hierarchie zwischen Arbeitsspeicher und Festplatten eingeordnet werden kann. Ihr Platz in der Speicher-Hierarchie begründet auch, warum sie Festplatten bisher nicht hat ablösen können. (Festplatten werden in Sektion näher beschrieben, Solid-State-Drives in Sektion Sektion stellt beide Geräteklassen gegenüber.) Es entstand die Idee, im Sinne der Speicherhierarchie ein Solid-State- Drive als Cache für eine Festplatte einzusetzen, um den Zugriff auf die Festplatte zu beschleunigen. Während sich Busse (2010) mit Caching auf Ebene des Blockgeräts beschäftigt hat, geht es in dieser Arbeit um Caching auf Dateisystemebene. Der konkrete Ansatz wird in Kapitel 5 auf Seite 37 in Detail vorgestellt Festplatten (HDDs) In einer Festplatte verbindet eine Achse mehrere übereinander angebrachte, kreisförmige Scheiben, genannt Platter, die sich drehen und nach Busse (2010) mittels magnetischer Ausrichtung eine Menge an Bits repräsentieren können. Ein Platter ist in mehrere Spuren eingeteilt, die mit wachsendem Radius kreisförmig um die Drehachse verlaufen. Eine Spur ist unterteilt in Sektoren, die bis vor kurzem 512 Byte speicherten, inzwischen aber üblicherweise 4096 Byte vorhalten. Nach Garcia-Molina u. a. (2001) variiere die Anzahl der Sektoren pro Spur. Nach Busse (2010) befinde sich zwischen je zwei Sektoren eine Lücke, die zur Kalibrierung des im Folgenden beschriebenen Lese-/Schreibkopfes genutzt werde. 19

22 KAPITEL 1. EINFÜHRUNG Beide Seiten eines Platters können Daten vorhalten, weshalb je Seite und Platter ein Lese-/Schreibkopf vorhanden sei, der über den Plattern schwebe, sie aber in ordnungsgemäßem Betrieb nicht berühre. Ein Arm bewegt alle Leseköpfe gleichzeitig von Zylinder zu Zylinder: der Menge aller Spuren mit gleichem Radius. Durch die Drehung der Platter lässt sich über Zeit jeder Punkt ihrer Oberfläche von den Lese-/Schreibköpfen erreichen. Abbildung 1.2 visualisiert diesen Aufbau. Spuren Achse Arm Lese-/Schreibkopf Abbildung 1.2: Aufbau einer Festplatte Platter Um einen bestimmten, aber beliebigen Sektor auszulesen, muss zuerst der Lese-/Schreibkopf auf den entsprechenden Zylinder bewegt werden. Bis der Anfang des gesuchten Sektors den Lese-/Schreibkopf erreicht, kann eine volle Drehung der Platter nötig sein; im Durchschnitt ist eine halbe Drehung nötig. Die durchschnittliche Zugriffszeit kann daher wie folgt berechnet werden: Zugriffszeit[ms] = Spurwechselzeit[ms] Drehzahl[ 1 min ]. Der Festplatten-interne Cache von mehreren Megabyte Größe wird in dieser Rechnung noch nicht berücksichtigt. Festplatten seien laut Busse (2010) in Gebrauch, weil sie kostengünstig große Mengen an Speicher bieten, der schnell sequentiell gelesen werden könne. 20

23 KAPITEL 1. EINFÜHRUNG Solid-State-Drives (SSDs) Vergleich zwischen HDDs und SSDs Festplatten und Solid-State-Drives unterscheiden sich aus Sicht des Anwenders in folgenden Eigenschaften: Anschaffungskosten Der Preis pro Byte ist beim Solid-State-Drive aktuell höher als bei der Festplatte. Performanz Die Performanz eines Solid-State-Drives übersteigt die einer Festplatte üblicherweise um Faktor Drei oder mehr: Die Zugriffszeit ist daher geringer und der Datendurchsatz höher. Kapazität Solid-State-Drives erreichen aktuell ein Volumen von einem Terabyte, während Festplatten von bis zu vier Terabyte Größe auf dem Markt zu finden sind. Zugriffsmuster Die Stärke der Festplatte ist sequentieller Zugriff, die Stärke des Solid- State-Drives dagegen ungeordneter Zugriff. Geräuschentwicklung Die Rotation einer Festplatte erzeugt Geräusche. Der Betrieb eines Solid- State-Drives ist lautlos, da keine mechanische Bewegung stattfindet. Wärmeentwicklung Ein Solid-State-Drive entwickelt beim Betrieb weniger Wärme als eine Festplatte. Gewicht Solid-State-Drives sind bei gleicher Speicher-Größe leichter als Festplatten. Schaden bei Sturz Eine Festplatte besitzt im Gegensatz zum Solid-State-Drive mehrere Lese-/Schreibköpfe, die die Platter nach Busse (2010) nicht berühren dürfen. Ein Solid-State-Drive ist daher weniger anfällig für Schäden durch Sturz als eine Festplatte, 21

24 KAPITEL 1. EINFÜHRUNG Abnutzung im Betrieb Während die Abnutzung der Festplatte durch bewegliche Teile entsteht, nutzt sich ein Solid-State-Drive durch das Schreiben der Flash-Bausteine ab. 22

25 Kapitel 2 Problemstellung Das übergeordnete Ziel diese Arbeit ist das Folgende: Das Verkürzen von Disk-I/O-verschuldeten Wartezeiten in Bezug auf typische Anwendungsszenarien bei Nutzung eines GNU/ Linux-Desktop-Systems mit der Absicht, die User Experience zu verbessern. Hierbei soll das System sinnvoll um ein Solid-State-Drive erweitert werden. Weiterhin soll ein Lösungskonzept folgende Bedingungen erfüllen: 1. Das System unterstützt das Lesen und Schreiben von Dateien. 2. Das Gesamtsystem arbeitet auch bei Komplettausfall des Solid-State- Drives fehlerfrei. 3. Das Gesamtsystem arbeitet auch bei Überlaufen des Solid-State-Drives fehlerfrei. 4. Auf Hintergrund-Threads wird zu Gunsten der Systemlast verzichtet. 23

26

27 Kapitel 3 Grundlagen Dieses Kapitel vermittelt Wissen, das in den folgenden Teilen der vorliegenden Arbeit vorausgesetzt wird. Sektion 3.1 stellt die Arbeitsweise des von der prototypischen Implementierung verwendeten Frameworks FUSE vor. Sektion 3.2 stellt das Konzept eines Stackable file systems und dessen Umsetzung im User space vor. 3.1 FUSE FUSE ist ein Framework für die Entwicklung von Dateisystemen, die als Prozesse im User space laufen. Es besteht aus einer Bibliothek libfuse, auf der jedes FUSE-Dateisystem aufbaut, und einem Kernel-Modul, das die Brücke zwischen Kernel und libfuse schlägt. Attraktiv ist FUSE dadurch, dass es die Entwicklung eines Dateisystems deutlich vereinfacht, da der Entwickler den Quellcode des Kernels weder verstehen noch erweitern muss. 25

28 KAPITEL 3. GRUNDLAGEN Anwendung FUSE-Dateisysem User space libfuse Kernel space VFS-Schicht FUSE Abbildung 3.1: Architektur von FUSE Greift eine Anwendung auf eine Datei zu, die einem FUSE-basierten Dateisystem zugeordnet ist, leitet das FUSE-Kernel-Modul die Anfrage an den verantwortlichen Prozess im User space weiter. FUSE erlaubt einem Dateisystem laut Quellcode-Datei fuse/fuse.h in Version 2.8.6, die folgenden Operationen zu implementieren: access Zugriffsrechte auf eine Datei prüfen create / creat Datei erstellen chmod Zugriffsrechte einer Datei verändern chown Eigentümer einer Datei verändern fgetattr / fstat Eigenschaften einer geöffneten Datei auslesen flush Schreiben gecacheter Daten anstoßen fsync Datei-Inhalte synchronisieren fsyncdir Ordner-Inhalte synchronisieren ftruncate Größe einer geöffneten Datei künstlich verändern getattr / lstat Eigenschaften einer Datei auslesen getxattr erweiterte Eigenschaft einer Datei auslesen link Hardlink zu einer existierenden Datei erstellen 26

29 KAPITEL 3. GRUNDLAGEN listxattr erweiterte Eigenschaften einer Datei auflisten lock Anfrage an das POSIX-Dateischloss der Datei stellen mkdir Ordner erstellen mknod spezielle Datei erstellen open Datei öffnen opendir Ordner öffnen read aus geöffneter Datei lesen readdir Ordnerinhalt lesen readlink Ziel eines Symlinks auslesen release / close geöffnete Datei schließen releasedir / closedir geöffneten Ordner schließen removexattr erweiterte Eigenschaften einer Datei löschen rename Datei umbenennen rmdir Ordner löschen setxattr erweiterte Eigenschaft einer Datei verändern statfs Eigenschaften des Dateisystems auslesen symlink Symlink erstellen truncate Größe einer Datei künstlich verändern unlink Datei löschen utimens Zugriffszeiten einer Datei verändern write in geöffnete Datei schreiben FUSE erlaubt somit die Implementierung vollwertiger Dateisysteme und ist daher aus funktionaler Sicht für die Implementierung von headcachefs geeignet. 27

30 KAPITEL 3. GRUNDLAGEN 3.2 Stackable file systems Der Begriff Stackable file systems existiert seit spätestens Heidemann u. Popek (1993). Ein Stackable file system ist ein Dateisystem, das zur Speicherung seiner Daten Dateien in einem anderen Dateisystem verwendet; effektiv wird eine Schicht mit Mehrwert über einem bestehenden Dateisystem eingefügt: dieser Mehrwert kann unter anderem Kompression, Fehlerkorrektur, Verschlüsselung, Protokollierung oder Replikation umfassen. Derartige Dateisysteme lassen sich stapeln, daher der Name Stackable file system. Sipek u. a. sprechen von einer oberen und einer unteren Schicht: die obere Schicht bezeichnet dabei das Stackable file system und die untere Schicht bezeichnet das Dateisystem, das intern zur Speicherung der Daten verwendet wird. Die vielleicht prominentesten Vertreter für Stackable file systems sind ecryptfs (aus Halcrow (2005)) und UnionFS (aus Quigley u. a. (2006)). Ersteres bietet Verschlüsselung an, letzteres Verschmelzung mehrerer Verzeichnisbäume zu einem einzigen Verzeichnisbaum. User space Anwendung readdir() vfs_readdir() Kernel space VFS-Schicht unionfs_readdir() UnionFS ext4 ext4 ext4_readdir() xfs_file_readdir() xfsxfs btrfs btrfs btrfs_real_readdir() Abbildung 3.2: Stackable file system UnionFS Abbildung 3.2 veranschaulicht, wie Aufruf readdir aus einem User space- 28

31 KAPITEL 3. GRUNDLAGEN Prozess heraus durch das Stackable file system UnionFS zu dessen Kindern propagiert wird Umsetzung im User space Stackable file systems lassen sich als Kernel-Modul oder mit FUSE im User space umsetzen. Auch im User space ist es möglich, ein Dateisystem auf Dateien zugreifen zu lassen, die durch das Stacking vor alle anderen Anwendungen verborgen sind. Angenommen, es existiert eine Datei /mnt/test/datei und ein Stackable file system ForwardFS wird gemountet nach /mnt/test. Ein Aufruf open("/mnt/test/datei", O_RDONLY); aus dem User space reicht FUSE als Aufruf von forward_fs_open("/datei", O_RDONLY); an den ForwardFS-Prozess weiter. ForwardFS will nun intern die eigentliche, ursprüngliche Datei /mnt/test/datei öffnen. Aus forward_fs_open heraus open("/mnt/test/datei", O_RDONLY); aufzurufen, ergäbe eine Endlosschleife über den Kernel und FUSE zurück zu ForwardFS. Um dieses Problem zu lösen, benötigt ForwardFS eine Referenz auf den ursprünglichen, darunterliegenden Ordner /mnt/test/, zu dem datei als relativer Pfad geöffnet werden kann. Die folgenden zwei Wege kommen in Frage: A) Vor dem Mounten durch einen chdir-aufruf das Arbeitsverzeichnis nach /mnt/test/ wechseln. So werden auch nach dem Mounten relative Pfade gegen den ursprünglichen Ordner /mnt/test/ aufgelöst. Ein interner Aufruf open("datei", O_RDONLY); arbeitet dann wie gewünscht. B) Vor dem Mounten durch einen Aufruf von int lower_dir_fd = open("/mnt/test/", O_DIRECTORY); einen File descriptor auf den ursprünglich Ordner offenhalten, danach mittels openat(lower_dir_fd, "datei", O_RDONLY); 29

32 KAPITEL 3. GRUNDLAGEN relativ zu diesen File descriptor arbeiten. Erwähnenswert sind noch zwei FUSE-Mount-Optionen, die für ein Stackable file system zwingend notwendig sind: Option nonempty erlaubt überhaupt erst das Mounten auf einen Ordner, der nicht leer ist. Option use_ino erlaubt es, selbst Zahlen für Inodes zu vergeben. Ohne diese Option tragen mehrere Hardlinks auf dieselbe Datei nicht dieselbe Inode-Zahl, wodurch beispielsweise die Berechnung von genutztem Speicher durch eine Nutzer-Anwendung falsche Ergebnisse liefern würde. 30

33 Kapitel 4 Vorhandene Ansätze In diesem Kapitel werden vorhandene Ansätze vorgestellt, bewertet und verglichen. Ein Dateisystem-basierter Ansatz wird motiviert. 4.1 SSD-basiertes Caching von Blockgeräten 4.2 SSD-basiertes Caching von Dateien FS-Cache FS-Cache ist ein Caching-Framework, das im Linux-Kernel Caching für ausgewählte Dateisysteme anbietet. Zu diesen Dateisystemen gehören im Linux-Kernel mit Version lediglich NFS und AFS (Andrew File System) zwei Netzwerkdateisysteme. In Howells (2006) wird auch das ISO-9660-CD-ROM-Dateisystem als Kandidat für Unterstützung durch FS-Cache genannt. Diese Unterstützung ist bislang jedoch nicht implementiert. Das Backend von FS-Cache lässt sich austauschen. Zwei Backends stehen im Kernel zur Verfügung: Backend CacheFS erlaubt, per mount(1) ein Blockgerät ausschließlich Caching zu widmen, während Backend CacheFiles mit einem User space-programm cachefilesd zusammenarbeitet, um Cache-Daten als regulärer Dateien abzulegen. Da FS-Cache unterhalb der VFS-Ebene greift, muss jedes Dateisystem, das von FS-Cache profitieren will, spezielle Unterstützung implementieren. 31

34 KAPITEL 4. VORHANDENE ANSÄTZE mcachefs mcachefs 1 ist ein FUSE-basiertes Stackable file system, das intern auf zwei Ordnern arbeitet: einem für die Quelle und einen zum Ablegen von gecacheten Daten. Der Quelltext in Revision 22 vom 10. Oktober 2010 liegt vor. Neben Metadaten wie Zugriffszeiten und -rechten cachet mcachefs alle Dateien ohne Ausnahmen oder Unterschiede. Beim Öffnen einer Datei wird für diese Datei ein Eintrag in der Warteschlange für Backup-Aufträge angelegt. Das Lesen der Daten blockiert, bis der angefragte Bereich vollständig im Cache vorliegt, und liefert dann Daten aus dem Cache. Man könnte annehmen, dass so Daten in den Cache-Ordner geschrieben werden, die von dort erneut gelesen werden müssen. Wenn sie nicht verdrängt wurden, liegen kürzlich in den Cache geschriebene Daten aber auch im Page cache des Linux-Kernels vor, so dass Lese-Anfragen aus dem RAM bedient werden können. Für Schreibvorgänge verwendet mcachefs einen Write-Back-Cache. Sollte der Cache-Ordner beschädigt werden, so kann Datenverlust entstehen CacheFS CacheFS 2 ist ein FUSE-basiertes Stackable file system, das auf drei Ordnern auf jeweils verschiedenen Medien arbeitet: je ein Ordner auf einer Ramdisk, einem Solid-State-Drive und einer Festplatte. Die eigentlichen Daten befinden sich auf der Festplatte. Dateien werden als Ganzes abhängig von ihrer Größe entweder auf das Solid-State-Drive oder in den RAM kopiert. Der RAM wird hierbei bevorzugt, solange 1. der freie Speicher der Ramdisk das zulässt und 2. die Größe der Datei nicht eine feste Grenze überschreitet. Erhält CacheFS von FUSE den Befehl, eine Datei zu öffnen, wird mit dem Aufruf system( cp quelle ziel ) synchron die Datei auf eines der Cache- Medien kopiert, bevor die Datei intern mittels open geöffnet wird. Im Falle von größeren Dateien bedeutet das zusätzliche Wartezeit für den Benutzer. Schreibzugriff ist bisher nicht implementiert. Die Mountpoints des Solid- State-Drive und der Ramdisk sind nur im Quelltext konfigurierbar

35 KAPITEL 4. VORHANDENE ANSÄTZE In Hupca u. a. (2010) wird das Abstimmen von CacheFS auf Zugriffs- Profile von Anwendungen angedacht: alle im Zugriffsprofil vorkommenden Dateien werden auf Ramdisk und Solid-State-Drive abgelegt, so dass die Festplatte für diese spezielle Anwendung nicht mehr benötigt wird und auch um Strom zu sparen in den Ruhezustand übergehen kann. Auch der Einsatz eines Simulators wird erwähnt, aber nicht im Detail diskutiert Conquest Conquest ist ein Dateisystem, das nach Wang u. a. (2002) als Kernel-Modul für Linux Metadaten wie Zugriffszeiten und -rechte, sowie den Inhalt von Dateien kleiner als ein Megabyte in persistentem RAM speichert. Die restlichen Daten verbleiben auf einer herkömmlichen Festplatte. Als persistenter RAM liege batteriegestützter DRAM ( battery-backed DRAM ) im Fokus von Wang u. a. (2002), der auch BB-DRAM genannt werde. Ende 2001 sei es möglich gewesen, zwei Gigabyte BB-DRAM für 200 US-Dollar zu erwerben. Ein konkretes Produkt wird nicht genannt. Bei Shimpi (2005) lassen sich Spuren eines derartigen Produktes i-ram der Firma Gigabyte Technology finden, wenn auch aus dem Jahre Dass der Speicherbereich im persistenten RAM nicht wie ein Cache verwendet wird, sondern ausgewählte Daten speichert so wie die Festplatte auch, hat folgende Konsequenzen: Es liegen keine Daten mehrfach vor: Bedarf zur Synchronisation von Daten besteht daher nicht. Ausfall einer Komponente führt zum Ausfall des Gesamtsystems. Konkret ist die Zuverlässigkeit damit niedriger als die einer Festplatte im Alleinbetrieb. Wang u. a. vermuten, dass die weitere Steigerung der Performanz möglich ist, indem ausführbare Dateien und die dazugehörigen Bibliotheken auch dann im persistenten RAM abgelegt werden, wenn sie die Trennlinie der Größenbeschränkung überschreiten xcachefs Sivathanu u. Zadok (2005) stellt das universelle Caching-Dateisystem xcachefs für Linux vor. xcachefs arbeite auf zwei Kind-Dateisystemen, die Sivathanu u. Zadok Cache-Dateisystem und Quell-Dateisystem nennen. 3 Die aktuelle Version des Linux-Kernels liegt bei (Stand ). 33

36 KAPITEL 4. VORHANDENE ANSÄTZE xcachefs ist für das Caching sowohl von lokalen Dateisystemen als auch von Netzwerkdateisystemen konzipiert. Deshalb werden bei jedem Öffnen einer Datei die Metadaten von Cache-Dateisystem und Quell-Dateisystem verglichen, was bei exklusivem Zugriff nicht nötig wäre; auch werden Zugriffsrechte und Dateilistings ausschließlich dem Quell-Dateisystem entnommen, statt auf das Cache-Medium zurückzugreifen. Ab einer gewissen als Mount-Option spezifizierbaren Dateigröße cachet xcachefs eine Datei blockweise; unterhalb dieser Größe cachet es die gesamte Datei: Das kann beim Öffnen einer Datei zu Verzögerungen führen. Eine User space-anwendung überwache die Ausnutzung des Cache-Dateisystems und beginne, Dateien im Cache zu löschen, wenn eine obere Grenze an Verbrauch überschritten ist. Typisch sei nach Sivathanu u. Zadok (2005) hierfür ein Schwellwert von 90 Prozent Zusammenfassung Es stellt sich die Frage, inwiefern die vorgestellten, Dateisystem-nahen Ansätze die in Kapitel 2 auf Seite 23 gesetzten Voraussetzungen erfüllen. FS-Cache erfüllt die Grundvoraussetzungen. xcachefs verletzt die Anforderung auf Verzicht von Hintergrund-Threads indirekt durch den Einsatz einer User space-anwendung zur regelmäßigen Beschaffung freien Speichers. mcachefs verkraftet den Ausfall des Solid-State-Drives nicht, da ein Write-Back-Cache verwendet wird. Auch Conquest übersteht den Ausfall des Solid-State-Drives nicht: Der Grund ist hier, dass nicht alle Daten vollständig auf der Festplatte repliziert werden. CacheFS unterstützt nicht das Schreiben von Dateien und erzwingt darüber hinaus spürbare Wartezeiten beim Öffnen von Dateien. Die Tabelle 4.1 auf Seite 35 fasst die existierenden Ansätze zusammen. 34

37 KAPITEL 4. VORHANDENE ANSÄTZE Unterstützt Verkraftet Verkraftet Verzicht auf Schreiben Ausfall SSD Überlauf SSD Worker-Threads FS-Cache ja? 2,3? 2,3? 2 mcachefs ja nein? 2,3 nein CacheFS nein? 2,3? 2,3? 2 Conquest ja nein? 1,3? 2 xcachefs ja? 1,3? 1,3 nein 4 Tabelle 4.1: Zusammenfassung vorhandener Ansätze 1 Quellcode liegt nicht vor 2 nicht näher untersucht 3 Vermutung: negativ 4 in Form einer separaten User space-anwendung 35

38

39 Kapitel 5 Ansatz In diesem Kapitel werden die Unzulänglichkeiten existierender Ansätze aufgezeigt, die zu dem Ansatz geführt haben, der in dieser Arbeit untersucht wird. Im Folgenden wird dieser Ansatz selbst vorgestellt. Dabei werden verschiedene Klassen von Grenz-Algorithmen beschrieben, die zur Kontrolle des Datenflusses eingesetzt werden können. Eine erste Vorauswahl wird getroffen und gerechtfertigt. 5.1 Unzulänglichkeiten vorhandener Ansätze Einschränkungen auf Blockgeräteebene Blockgerät-basierte Ansätze folgen der Annahme, dass zukünftige Zugriffe auf Daten vergangenen Zugriffen ähneln, und halten daher Daten vor, auf die bereits in der Vergangenheit zugegriffen wurde. Vor dem ersten Start einer Anwendung kann die zugehörige Datei daher noch nicht im Cache vorliegen. Erst die Betrachtung der Zusammenhänge von Datenblöcken auf Dateiebene ermöglicht die differenzierte Behandlung von unterschiedlichen Klassen von Dateien. Beispielhafte Unterscheidungen sind die Trennung in Nutzer- und System-Dateien, kleine und große Dateien oder Musik- und andere Dateien. Bei Caching auf Blockgeräteebene sind Dateizusammenhänge nicht ersichtlich, was Optimierungen zu Gunsten ausgewählter Dateien einschränkt. 37

40 KAPITEL 5. ANSATZ Blockgerät-basierte Verfahren, wie beschreiben in Busse (2010), sind hiervon betroffen Ungünstige Entscheidungen auf Dateisystemebene Die Systeme von mcachefs oder Conquest verkraften keinen vollständigen Ausfall des Solid-State-Drives, sei es, weil ein Write-Back Cache verwendet wird, sei es, weil nicht alle Dateien auch vollständig auf der Festplatte vorliegen. Das Gesamtsystem ist somit weniger ausfallsicher als die Festplatte allein. Die Systeme FS-Cache und Conquest sind nicht als Stackable file systems implementiert, weshalb sie sich nicht eigenen, um mit existierenden Dateisystemen wie ext4 oder XFS zusammenzuarbeiten; eine Anpassung für jedes einzelne Ziel-Dateisystem wäre nötig. Der Ansatz von mcachefs und xcachefs verlangt keine exklusive Nutzung des Datenbereichs auf der Festplatte und muss daher darauf vorbereitet sein, dass durch externen Einfluss im Handlungsbereich von xcachefs neue Dateien erscheinen. In solchen Fällen werden daher Wartezeiten bei den Operationen open und read oder aber der Betrieb von Hintergrund-Threads in Kauf genommen, wodurch sich Wartezeiten verlängern beziehungsweise sich die Systemlast erhöht. Durch eine Entscheidung für exklusive Nutzung des betroffenen Bereichs der Festplatte kann die Leistung des Dateisystems erhöht und das Design vereinfacht werden. 5.2 Ansatz dieser Arbeit Es bietet sich an, bevorzugt Daten aus kleinen Dateien auf dem schnellerem Speichermedium dem Solid-State-Drive vorzuhalten. Zwei Umstände weisen in diese Richtung: Wang u. a. (2006) fasst existierende Untersuchungen über die Größen von Dateien zusammen. Folgende Beobachtungen werden gemacht: 1. Der Großteil der Dateien sei klein. 2. Der Großteil der Zugriffe betreffe kleine Dateien. 3. Der Großteil des Platzbedarfs betreffe große Dateien. Wegen 2. sollte besonders der Zugriff auf kleine Dateien beschleunigt werden. 38

41 KAPITEL 5. ANSATZ Es ist anzunehmen, dass sich Menschen bei der Arbeit mit großen Datenmengen nicht über Wartezeiten wundern, bei kleinen Datenmenge dagegen aber wenig Verständnis für Wartezeiten aufbringen können. Diese These wird hier nicht näher untersucht, sondern als wahr angenommen: Eine nähere Untersuchung würde den Rahmen dieser Arbeit sprengen und fällt zudem in ein anderes Fachgebiet. Zwei unterschiedliche Vorgehensweisen sind denkbar: Trennung Die ersten k Byte der Kopf jeder Datei wird auf dem Solid-State- Drive gespeichert, die folgenden Byte der Rumpf wird auf der Festplatte gespeichert. Daten werden also über Solid-State-Drive und Festplatte verteilt. Replikation / Caching Die ersten k Byte jeder Datei werden auf dem Solid-State-Drive gespeichert es fungiert als Cache. Die Festplatte hält alle Dateien vollständig vor, Daten werden auf dem Solid-State-Drive repliziert. Die Trennung von Daten ist jedoch problematisch: Arbeiten mit den Dateien außerhalb des Systems ist nicht möglich: Die Dateien im Quell-Dateisystem sind ohne Ergänzung durch das Cache-Dateisystem unvollständig. Die Ausfallsicherheit des Gesamtsystems ist geringer als die der Festplatte allein. Daher fiel die Wahl für diese Arbeit auf einen Caching-Ansatz. Werden die ersten k Byte jeder Datei der Festplatte auf dem Solid-State-Drive repliziert, so finden sich von Dateien, die insgesamt nicht größer als k Byte sind, vollständige Kopien auf dem Solid-State-Drive. Dieser Umstand macht den Lese-Zugriff auf kleine Dateien schneller als auf große Dateien, bei denen ein Rest von der langsameren Festplatte gelesen werden muss. Nun stellen sich folgende Fragen. Wie sollte die Grenze k gewählt werden? Ist k für alle Dateien gleich groß, also global, oder verschieden und damit lokal? Wäre es praktisch oder gar nötig, k über die Zeit anzupassen? Wenn ja, welchem Schema soll diese Veränderung folgen? In Wang u. a. (2002) wird die Änderung einer vergleichbaren Grenze bereits angedacht, aber nicht näher verfolgt. In Kapitel 8 auf Seite 69 wird auf diese Frage näher eingegangen. 39

42 KAPITEL 5. ANSATZ Bei der Arbeit auf Dateisystemebene stehen Metadaten wie Dateigröße und Dateipfad zur Inspektion und Entscheidungsfindung zur Verfügung. Die Betrachtung der Dateipfade ermöglicht es zum Beispiel, gezielt Dateien zum Caching auszuwählen, die zur Ausführung von Anwendungen benötigt werden, aber alle anderen Dateien vom Caching auszuschließen. Für eine Auswahl bieten sich hierbei Dateien an, deren Inhalt sich trotz Nutzung durch einen unprivilegierten Nutzer nicht verändert, die also mehrfach gelesen aber nicht geschrieben werden. Aus der Analyse eines für GNU/Linux typischen Datenbestandes ergibt sich die Liste der Ordner, deren Dateien sich für vollständiges Caching anbieten: Ausführbare Programmdateien /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin /usr/libexec Bibliotheken /lib32 /usr/lib32 /usr/local/lib32 /lib64 /usr/lib64 /usr/local/lib64 Architektur-unabhängige Daten /usr/share /usr/local/share System-Konfiguration /etc /usr/local/etc Vermischtes /opt Bei einer Variante dieses Ansatzes werden nur ELF-Dateien gecachet erkannt am charakteristischen Kopf beim Anlegen der Datei. Die Erkennung und spezielle Behandlung ist auch in Wang u. a. (2002) angedacht, wird aber nicht näher verfolgt. Zusammengefasst kann die Verteilung der Daten die Entscheidung, welche Daten auf dem Solid-State-Drive repliziert werden also abhängen von dateisystemweiten Einstellungen, der Dateigröße einer Datei, 40

43 KAPITEL 5. ANSATZ dem Pfad einer Datei, oder dem Inhalt einer Datei. Neben der Verwendung mit einem Solid-State-Drive ist dieser Ansatz auch in Verbindung mit tmpfs, also Arbeitsspeicher, denkbar. 5.3 Grenz-Algorithmen Der Begriff Grenz-Algorithmus bezeichnet einen Algorithmus, der zu jedem Zeitpunkt für jede Datei entscheiden kann, wie viele Byte einer Datei aus dem Quell-Dateisystem in das Cache-Dateisystem übertragen werden sollen. Durch Größen-Veränderungen anderer Dateien kann sich über die Zeit für eine Datei diese Grenze k verschieben. Die Erhöhung dieser Grenze kann nur durch das Schreiben von Daten am Ende der entsprechenden Datei im Cache-Dateisystem umgesetzt werden, da sonst Lücken in der Cache-Datei entstehen würden. Bei Verringerung dieser Grenze bestehen dagegen drei verschiedene Möglichkeiten, mit diesem neuen Wissen umzugehen. Es lassen sich folgende Methoden unterscheiden: Statisch Die neu berechnete Grenze wird verworfen und die ursprüngliche Grenze wird weiter verwendet. Dynamisch: bei Zugriff Bei ausgewählten Operationen wird die neue Grenze umgesetzt. Dateien, auf die später nicht zugriffen wird, verändern sich daher nach dem Anlegen nicht wieder. Dynamisch: kontinuierlich Ein Hintergrund-Thread korrigiert regelmäßig die Größen aller Dateien. Des Weiterem kann vom Füllstand des Cache-Dateisystems abhängig gemacht werden, ob die Verschiebung einer Grenze umgesetzt wird, ob ein Hintergrund-Thread arbeitet oder im Ruhezustand verharrt. Im Folgenden werden verschiedene Grenz-Algorithmen vorgestellt. 41

44 KAPITEL 5. ANSATZ Algorithmus fixed Dieser Grenz-Algorithmus erlaubt, für jede Datei im Cache maximal k Byte zu speichern. Dateien einer Größe kleiner oder gleich k werden demnach vollständig gecachet; somit werden kleine Dateien besser behandelt als große. Eine sinnvolle Wahl des Parameters k hängt also von der geplanten Nutzung des Dateisystems ab. Die im Folgenden beschriebenen Spezialfälle verdienen besondere Aufmerksamkeit Fall Null Dieser Fall eignet sich, den minimalen Mehraufwand gegenüber hookfs, einem FUSE-Dateisystem, das lediglich Anfragen an einzelnes Kind-Dateisystem weiterleitet, zu bestimmen Fall unbeschränkt Dieser Fall eignet sich, zu prüfen, wie sich ein explizit naiver Ansatz im Vergleich zu durchdachten Alternativen schlägt Fall optimal Wird das Dateisystem in einem Testlauf betrieben, bei dem der zu erwartenden Datenfluss vollständig bekannt ist, so kann eine Grenze im Voraus berechnet werden, die die Gesamtlaufzeit minimiert. Ein solcher Wert entspricht dem mit einer festen Größe erreichbaren Optimum Algorithmus equalshare Dieser Grenz-Algorithmus erlaubt jeder Datei, im Cache so viel Speicher zu belegen, wie bei gleicher Verteilung entsteht: bei drei Dateien ein Drittel des Gesamtspeichers, bei vier Dateien ein Viertel des Gesamtspeichers. Angenommen dem Cache-Dateisystem ist ein Speichervolumen von drei Gigabyte zugeteilt. Kopiert ein Nutzer nun der Reihe nach zehn Dateien auf headcachefs, sinkt die Grenze mit dem Erstellen jeder weiteren Datei: 3 Gigabyte, 1,5 Gigabyte, 1 Gigabyte, 0,75 Gigabyte bis 0,3 Gigabyte. Abbildung 5.1 zeigt ein Beispiel für Algorithmus equalshare mit fünf Dateien auf einem Cache-Dateisystem der Speichergröße 100 Byte. Die Grenze 42

45 KAPITEL 5. ANSATZ für jede Datei liegt zum abgebildeten Zeitpunkt bei Gesamtspeicher Anzahl Dateien = 100 Byte 5 = 20 Byte Algorithmus aimfull Algorithmus aimfull basiert auf dem Algorithmus equalshare. Bei fünf Dateien und einem Gesamtspeicher von 100 Byte im Cache-Dateisystem ermittelt equalshare eine Obergrenze von = 20 Byte Algorithmus "equalshare" Speicher im Cachedateisystem: 100 Bytes Quell-Dateisystem Cache-Dateisystem 50 Dateigröße [Byte] a b c d e Datei Abbildung 5.1: Grenz-Algorithmus equalshare Eine Datei der Größe 10 Byte schöpft diesen Vorrat nicht aus: Drei Dateien zu je 10 Byte Größe sparen insgesamt (20 10) 3 = 30 Byte, die auf die Dateien aufgeteilt werden, die mit Algorithmus equalshare nicht vollständig gecachet werden können. Die Grenze wird daher um 30 2 = 15 Byte von 20 Byte auf = 35 Byte verschoben; der Füllgrad des Cache ist in diesem Beispiel mit Algorithmus aimfull somit höher als mit Algorithmus equalshare und erreicht das Maximum von 100 Prozent. 43

46 KAPITEL 5. ANSATZ Algorithmus "aimfull" Speicher im Cachedateisystem: 100 Bytes Quell-Dateisystem Cache-Dateisystem 50 Dateigröße [Byte] a b c d e Datei Abbildung 5.2: Grenz-Algorithmus aimfull Dateigrößen-basierte Algorithmen Auch die Betrachtung Dateigrößen-basierter Grenz-Algorithmen war zunächst für diese Arbeit vorgesehen. Ein Beispiel ist, die maximale Dateigröße im Cache-Dateisystem von der Quadratwurzel der Dateigröße im Quell-Dateisystem abhängig zu machen, ein anderes, die Grenze auf 10 Prozent der Dateigröße festzusetzen. Das Verhältnis aus Kapazität der Festplatte und dem Solid-State-Drive bietet sich hier als Faktor an. Dieser Ansatz lässt sich leider nicht effizient umsetzen. Angenommen, eine Datei wird von außerhalb auf das headcachefs Dateisystem kopiert. Intern ergibt sich eine Reihe von write-aufrufen von je 4096 Byte Daten. Erst nach Verarbeitung aller Schreib-Anfragen beim Aufruf von release ist die Dateigröße bekannt: Das ist zu spät. Schreibt einer der write-aufrufe weniger als 4096 Byte Daten in die Cache-Datei, so entsteht beim darauffolgenden write-aufruf eine Lücke in der Cache-Datei, was beim Lesen fälschlicherweise eine Reihe von Null-Werten liefern würde, obwohl die Datei im Quell-Dateisystem für den angefragten Bereich echte Daten vorhält. Um dies zu verhindern, müsste die gesamte Datei ins Cache-Dateisystem kopiert werden, um dann im release-aufruf bereits geschriebene Daten 44

47 KAPITEL 5. ANSATZ wieder freizugeben, um die Größenrichtlinie umzusetzen. Dieser Ansatz erscheint nicht sinnvoll. Daher wurde entschieden, auf die Verwendung von Grenz-Algorithmen zu verzichten, bei denen die Größe der jeweiligen Datei im Quell-Dateisystem die Größe der Datei im Cache-Dateisystem mitbestimmt Inhalts-basierte Algorithmen Bei Inhalts-basierten Grenz-Algorithmen hängt die Menge der zu cachenden Daten vom Inhalt der konkreten Datei ab. So können beispielsweise MP3- Dateien anders behandelt werden als ELF-Binärdateien oder Text-Dateien. Voraussetzung für die unterschiedliche Behandlung ist die Zuordnung der Datei zu einer bestimmten Klasse von Dateien. Benötigt die Erkennung einer bestimmten Datei-Klasse Zugriff auf Daten jenseits des Dateianfangs, entstehen Probleme ähnlich denen, die in Sektion für Dateigrößenbasierte Grenz-Algorithmen beschrieben sind: Die Antwort auf die Frage, wie viele Byte gecachet werden sollen, wird benötigt, bevor sie zur Verfügung steht. Eine oberflächliche Erkennung von ELF-Binärdateien könnte nach TIS Committee (1995) die ersten vier Byte einer Datei mit der Hexadezimal-Folge 7f, 45, 4c, 46 vergleichen. Solange beim Erstellen der Datei der erste write- Aufruf am Dateianfang ansetzt und vier oder mehr Byte an Daten liefert, verursacht diese Erkennung selbst keine weiteren Schwierigkeiten. Bei jeder späteren Veränderung einer Datei muss der Dateityp allerdings wieder bekannt sein, um zu entscheiden, wie sich die Größe der Datei im Cache-Dateisystem verändern darf. Entweder muss der Dateityp dynamisch neu erkannt werden oder auf das Ergebnis der ersten Analyse dieser Datei zurückgegriffen werden. Für die Umsetzung des letzteren Falles muss ein Speicherort für diese Informationen gefunden und reserviert werden. 45

48

49 Kapitel 6 Design In diesem Kapitel werden das Design von headcachefs und die damit verbundenen Herausforderungen detailliert vorgestellt. 6.1 Überblick Aus funktionaler Sicht geht es darum, in die gängigen, existierenden Dateisysteme der Linux-Welt SSD-basiertes Caching einzubauen. Auf bestehende Dateisysteme Einfluss zu nehmen, ist allgemein, soweit es die Art des gewünschten Einflusses erlaubt, auf zwei Wegen möglich: von innen durch Anpassung jedes einzelnen Dateisystems oder von außen durch Implementieren eines einzigen Stackable file systems. Die Arbeitsweise und Umsetzung von Stackable file systems wird in Sektion 3.2 auf Seite 28 näher beschrieben. Anstatt also an ext4 und XFS ähnliche Änderungen vorzunehmen, wird das gewünschte Feature als neue Schicht oben aufgesetzt. Um den Umfang der vorliegenden Arbeit zu reduzieren, ist die Entscheidung auf diesen Weg gefallen. Als Stackable file system greift headcachefs auf zwei ungleiche Kind- Dateisysteme zu, die im Verlauf der Arbeit in Einklang mit Sivathanu u. Zadok (2005) zur Unterscheidung das Quell-Dateisystem und 47

50 KAPITEL 6. DESIGN das Cache-Dateisystem genannt werden. Dabei arbeitet Ersteres auf einer Festplatte, während Letzteres auf ein Solid-State-Drive zurückgreift. Die ersten k Byte jeder Datei werden hierbei auf dem Solid-State-Drive vorgehalten, was auf Kosten eines Mehraufwandes beim Schreiben von Daten das Lesen von Daten beschleunigen soll. Die Abbildung 6.1 veranschaulicht diese Architektur. Anwendung Anwendung headcachefs Erweiterung ext4 ext4 ext4 HDD HDD SSD Vorher Nachher Abbildung 6.1: Überblick Architektur headcachefs Als Fundament der Implementierung wurde FUSE gewählt. FUSE steht für Filesystem in User space und erlaubt es, Dateisysteme zu entwickeln, die im User space statt im Kernel space laufen, daher deutlich leichter zu entwickeln sind und von einem unprivilegierten Nutzer gemountet werden können. Ein wichtiger Grund bei der Entscheidung für FUSE war, die Entwicklung von headcachefs nicht weiter zu verkomplizieren. Die Funktionsweise von FUSE wird in Sektion 3.1 auf Seite 25 näher beschrieben. 6.2 Funktionsweise Jeder Eintrag für eine Datei oder einen Ordner liegt sowohl im Quell-Dateisystem als auch im Cache-Dateisystem vor. Abbildung 6.2 veranschaulicht 48

51 KAPITEL 6. DESIGN diesen Aufbau. /headcachefs /quelle /cache /HEADCACHEFS_STORE /datei1 /datei1 /datei1 /datei2 /datei2 /datei2 /ordner1 /ordner1 /ordner1 /datei3 /datei3 /datei3 Abbildung 6.2: Replikation von Dateisystem-Einträgen in headcachefs Er besticht durch Simplizität sowie die Möglichkeit, Symlinks ohne Zugriff auf die Festplatte auflösen zu können. Des Weiteren kann im Falle eines Fehlers, zum Beispiel bei einer Lösch-Anfrage für eine nicht-existente Datei, mitunter auf einen Festplatten-Zugriff verzichtet werden, wenn auf dem Cache-Dateisystem als Erstes operiert wird. Beim Lesen von Daten kann je nach Größe der Cache-Datei gegebenenfalls nicht nur auf die Festplatte sondern auch auf die Solid-State-Drive zurückgegriffen werden. Beim Schreiben von Daten entscheidet ein Grenz- Algorithmus, auf welche Größe die jeweilige Cache-Datei wachsen darf. Ein Überblick über Grenz-Algorithmen wird in Sektion 5.3 auf Seite 41 gegeben. Für den Zugriff auf Metadaten kann ohne Weiteres nicht auf Festplatten- Zugriffe verzichtet werden. Die folgenden Dateisystem-Operationen liefern Metadaten aus: fgetattr/fstat Eigenschaften einer geöffneten Datei auslesen getattr/lstat Eigenschaften einer Datei auslesen readdir Ordnerinhalt lesen Die POSIX-Operation fstat/lstat macht hierbei alle Metadaten einer Datei gemeinsam verfügbar, Operation readdir liefert lediglich Informationen über die Inode-Zahl und den Datei-Typen (Ordner, Named pipe,... ) aus. Während der Datei-Typ durch den in Sektion 6.2 beschrieben Aufbau bereits im Cache-Dateisystem durch ein Äquivalent repliziert wird, ist dies für Metadaten wie die Inode-Zahl oder Dateigröße bereits nicht mehr möglich. Eine Alternative bietet das Caching von Metadaten, das in in Sektion auf Seite 52 beschrieben ist. Da das Quell-Dateisystem weiterhin eigenständig nutzbar bleiben soll, wenn auch nicht während der Nutzung durch headcachefs, werden die Da- 49