 Okay, ja, herzlich willkommen auf der intergalaktischen Erfahrungsreise heute Mittag zu meinem Vortrag Disk Space The Final Frontier und ich dachte mir, ich mache das so ein bisschen als visuelle Erfahrungsreise, weil es sonst üblicherweise etwas trockener Stoff ist, aber ihr werdet gleich sehen, ich habe das ein bisschen angehübscht. Ich bin Benedikt Reuschling, ich gebe normalerweise Talks auf Konferenzen im BSD-Umfeld und beschäftige mich mit ZFS, deswegen auch dieser Vortrag hier. Ich mache viel Tutorials, ich gebe auch eine Vorlesung, obwohl ich kein Professor bin, an der Hochschule Darmstadt zu Unix-Themen und da ist ZFS auch ein Teil drin. Das ist aber bei mir leider immer sehr trockener Stoff, weil es ist immer eine Folienschlacht aus, weil ich immer sehr viel Text produziere, aber relativ wenig Bilder da reinbringe, das kriege ich auch immer so als Feedback. Mit den neuen Tools, die uns KI und Language Models und wie sie alle heißen, Dolly und Co liefern, dachte ich mir, hey, machst du mal genau das Gegenteil, produziere ein paar Bilder und dazu den Text, dass das Ganze ein bisschen aufgehübscht wird. Und dann dachte ich mir, hey, du kannst auch eine Story drumherum bauen, dass das quasi ein bisschen zugänglicher ist für das Publikum. Und das habe ich jetzt hier gemacht und versuche damit quasi so ein bisschen das Thema Open-ZFS nicht nur zu motivieren, sondern auch so ein bisschen unterhaltsam fortzutragen. Und das Ganze ist ein Experiment, das kann Hori ziemlich schief gelaufen oder ich sage, komm, das war jetzt vielleicht nicht so das beste Bild auf der Folie, aber hey, warum nicht, da kann man auch mal ausprobieren. Was ich schon festgestellt habe bei diesen ganzen Bildgeneratoren, ich habe den von Bing verwendet, weil das keine besondere Vorliebe ist zu Bing, aber da ging es für mich relativ schnell, Bilder zu erzeugen. Bei den Bildern ist es so, wie mit Urlaubsbildern, man macht 100 Fotos und von denen schmeißt man hinterher dann 95 wieder weg, weil da kommen halt teilweise Bilder raus, die dann überhaupt keinen Sinn ergeben oder die Gliedmaßen und Proportionen überhaupt nicht stimmen, gerade bei Menschen, also ich habe festgestellt, wenn man so Leute mit sechs Händen bekommen oder mehreren Fingern, die eigentlich da nicht hingehören, das ist halt schon irgendwie merkwürdig, obwohl der Rest des Bildes vielleicht okay aussehen würde. Also deswegen dachte ich mir, wir probieren das mal und lassen uns einfach mal jetzt auf die Reise gehen zu den fernen Sternen. Es beginnt damit, dass eben der große Plan gefasst wurde, einfach eine Weltraumreise anzutreten und dazu ein entsprechendes Schiff zu bauen, das eben die Crew auch hinterher wieder sicher nach Hause bringt und unterwegs das Ganze sozusagen zusammenhält. Bei der Reise für den Sternen soll auch die Galaxien natürlich erforscht werden und viele Daten gesammelt werden, wie das nun mal so passiert und dabei wurde sozusagen als zentrales Element der Schiffskomputer rausgesucht, weil eben da vieles zusammenläuft und auch da die Daten abgespeichert werden, die dann da gesammelt werden und die Ingenieure, die sich das ausgedacht haben mit meiner fiktiven Story, die verwenden eben Open-ZFS als Storage Pool, um da die Daten abzuspeichern und auch das gesamte Schiff irgendwie so zu kontrollieren und zusammenzuhalten. Und man hat gedacht, naja, die verwenden Standardbesatzung, inklusive eines sogenannten Schiff-Storage-Engineers, der oder die, ich habe das offen gelassen, sich um diesen Storage Pool kümmert, um das interne, dass das funktioniert, auch weiter funktioniert und eben auch die Daten sicher abgelegt werden oder falls mal was passiert, bestimmten Szenarien, dass man auch jemanden hat, der das Ding wieder zusammenbringen kann. Okay, also machten sich die Ingenieure an das Werk, um eben eben dieses Schiff zu bauen und, naja, da wurden Pläne gewälzt und Pläne verworfen und wieder neue Pläne gemacht, um dann eben dieses Weltraumschiff zu ersteuern und dann eben auch viele interessante Konzepte darin umzusetzen. Dann ging es natürlich auch an den späteren Bau des Schiffs, also man merkt hier schon, da sind viele Ingenieurstunden reingeflossen und man hat dann auch verschiedene Designs gehabt, aber irgendwann war dann wirklich flugfähig und man hat damit auch sozusagen, dass die Werft verlassen können und hat das dann auch sozusagen mit einer Crew zusammen versuchten, den Weltraum zu bringen und das hat dann den ersten Startversuchen auch gut geklappt. Und dann wurde natürlich im Lauf dieses Baus natürlich auch dieser Raumschiff Speicher initial initiiert, also man muss irgendwie mal anfangen, diesen Raumschiff Pool, also dieser gesamte Storage in diesem Raumschiff wird zusammengefasst in einem sogenannten Pool und dieser Pool besteht aus mehreren Speichermedien, deswegen kann man den auch später noch erweitern, indem man mehrere Speichermedien noch hinzufügt oder größere eben um den Pool eben anwachsen zu lassen, wenn es nötig wird. Und das Kommando dafür ist eben Z Pool Create, um diesen Pool Initial zu erstellen. Da gibt man diesen Pool einen Namen, man hat jetzt hier den Raumschiffsnamen genommen, man kann den aber sagen, das ist kein Schlüsselwort, ist beliebig vergeben, ich habe den jetzt mal IGA 2023 genommen, weil 1701 war halt schon mehrfach vergeben. Und ich habe mir gedacht, naja, die wollen irgendwie eine Ausfallsicherheit haben, weil wenn die mal weit weg von der Erde sind, dann können die halt nicht mehr so schnell nochmal sozusagen eine Platte austauschen oder ein Storage Medium oder vielleicht gibt es da nix im All, was man schnell mal nehmen könnte. Deswegen haben sie quasi zwei Storage Medium genommen, was das jetzt genau für Medien sind, ob das ganz abgespacede Medien sind oder die klassische Festplatte SSD NVMe, das haben wir da hingestellt, das ist teilweise auch so ein bisschen futuristisch angehaucht, aber ich vermute, dass in Zukunft, wenn TTFS sich so weiterentwickelt, auch mit zukünftigen Storage Medium arbeiten kann, wie auch immer die aussehen mögen. Ich habe jetzt hier mal aufengelassen, Medium 1 und Medium 2 und das Mirror Schlüsselwort hier bedeutet einfach, dass die mit dem RAID 1 aufgebaut werden, das heißt, die Daten, die auf eine Platte wandern oder auf ein Speichermedium, die werden auf die andere Platte genauso gespiegelt, so dass man quasi parallel schreibt, was ein bisschen aufwendiger ist, aber wenn man die Daten wieder lesen will von beiden Medien gleichzeitig lesen kann, was das Ganze natürlich wesentlich beschleunigt. Und sobald man dieses Kommando abgesetzt hat, wird der Speich hier initialisiert und ist nach wenigen Sekunden sofort verfügbar im System gemountet, also das wird auch alles von diesem ZPUL CREATE Kommando übernommen und ist dann auch bereit sofort IO zu nehmen, das heißt, man kann sofort Daten drauf schreiben und Daten auch wieder lesen, also die musst du nicht erst noch mit Nullen vollgeschrieben werden oder in irgendeiner anderen Form initialisiert, sondern dieses eine Kommando macht das. Okay, also dann ist der Raumschulspeicher initialisiert und dann kann die Reise eigentlich sofort losgehen, das heißt, die Besatzung geht an Bord und man verabschiedet sich natürlich, weil es ist halt eine längere Mission und dann weiß man ja nicht so richtig, wie lange man seine Freunde und Bekannten wieder sieht und dann wird natürlich erstmal so ein initialer Check angeordnet, damit man auch sozusagen startklar ist und alle Systeme nominal sind, wie man sie so schön bezeichnet. Und das kann mit einem Status Check passieren, das heißt, das Storage Pool kann bestimmte Informationen über sich preisgeben, sozusagen wie gesund er ist oder es ist mehr oder weniger, also das erste Kommando da ist ZPUL Status. Das gibt eben ein Status aus, wie diese Storage Medien, die diesem Pool angeschlossen sind, hier sieht man sie dann nochmal, wie es denen geht, wenn da online steht, heißt es nicht, die sind irgendwo im Internet, sondern wie unsere Drucker früher, die waren auch immer online. Und hier ist es genauso, das heißt, diese Medien sind im System bekannt und verfügbar und können quasi Daten lesen und schreiben. Jetzt gibt es hier noch diese drei Spalten, Read, Write und Check Sum, das heißt, da werden, wenn da überall Null steht, das ist alles okay, wenn da Werte stehen, die größer als Null sind, dann sollte man sich vielleicht nochmal angucken, denn da wird quasi von dem Pool ausgegeben. Ich habe da irgendein Problem, wenn wir da beim Lesen, beim Schreiben oder bei beiden vielleicht, wenn das Gerät schon so dem Ende hinzugeht, oder den Prüfsummen. Das heißt, jedes Mal, wenn ich I.O. tätige, entweder lese auf die, lesen von der Platte oder schreiben auf die Platte, wird eine Prüfsumme gebildet und beim Schreiben wird eben diese Prüfsumme mit den Daten zusammen abgelegt. Und beim Lesen wird diese Prüfsumme mit den Daten gelesen und mit der Prüfsumme verglichen, die das Schiff oder die CPU von diesen Daten berechnet hat und dann eben verglichen mit den Daten, mit der Prüfsumme, die dazu gespeichert wurde. Und wenn die beiden nicht übereinstimmen, dann wird hier eben als Check Summe ein Fehler ausgegeben an dieser Stelle. Dieser Z-Pool-Status zeigt mir quasi also den Status an, wie gesund ist mein Pool, aber das zeigt mir noch überhaupt nicht, was ich überhaupt an Speicherkapazität habe. Dafür brauche ich ein zweites Kommando, das ist das Z-Pool-List-Kommando da unten und da werden verschiedene Namen ausgegeben. Also der Name meines Storage Pools, mit dem spreche ich nämlich immer diesen gesamten Storage Pool an, also ich muss jetzt nicht sagen Platte 1 oder Gerät 2 oder Speichermedium 15, sondern ich kann da genau alle diese zusammengefassten Speichermedien ansprechen. Da gibt es eine Größe, da gibt es eine Menge an Allokationen, wie viel da schon gespeichert wurde, vielleicht haben die Ingenieure da so ein paar Initiale Computer-Daten schon drauf gespielt, oder das Basisbetriebssystem von dem Raumschiff, das könnte ja auch schon eine Menge Speicher benötigen. Und dann wird natürlich der freie Speicher angezeigt, ich habe da jetzt mal Werte eingegeben, die ich mir denke, könnten für ein Raumschiff interessante Werte sein oder relativ große Speicher, man kann die aber relativ klein halten, man kann damit Megabyte anfangen, wenn man überhaupt so kleine Speichermedien hat, also das lässt sich beliebig in Megabyte, Gigabyte, Terabyte, Exabyte. ZFS ist 2.228 Allokierbar, das heißt man kann da relativ viel speichern und kommt nicht an irgendeinen Limit, das heißt, man hat da relativ große Zukunftssicherheit. Okay, dann sieht alles soweit gut aus, also all systems go, wir können starten und dann verlässt die IGA auch das heimische Sternensystem und fliegt nun mal los ins Unbekannte, um eben seiner Mission die Daten zu sammeln und die Galaxie zu erforschen, zu nachzugehen. Und die erste Begegnung findet sozusagen mit den Redundanten statt, die habe ich mal so genannt, die nennen sich selber so. Am Tag 23, seit Missionsbeginn, die Crew checkt natürlich regelmäßig den Status des Pools und wie es ihr selbst natürlich auch geht, alles healthy und eines Tages erfassen eben Sensoren, ein nagelegender Nebel, ein paar Lichtjahre voraus und der Captain beschließt eben diesen zu untersuchen, was eben dieser Forschungsmission entspricht und dann fliegen die halt da hin zu dem Nebel, das kann natürlich auch ein bisschen dauern, aber wir sind ja hier mit Hyperlichtgeschwindigkeit unterwegs, da brauchen wir nicht lange warten und dann sind wir auch schon da, das heißt der Nebel liegt davor uns und unsere Sensoren sind alle fleißig am Daten sammeln und Forschungsdaten abspeichern auf dem Pool und plötzlich kommt eine Nachricht, dass Sensoren eben ein fremdes Schiff melden, das auch in diesem Nebel unterwegs ist und da wird natürlich die Grußfrequenz aktiviert und eine Grußbotschaft gesendet, wie man das halt so macht und dann kommt auch eine Antwort, ja wir sind also das Volk der Redundanten, wir sind hier auf einer Forschungsmission, da sagt der Captain auch super, das passt ja genau zu dem, was wir auch machen und lass uns das doch beim gemeinsamen Abendessen auf der IGA genauer besprechen, vielleicht kommen wir da auf gemeinsame Forschungsergebnisse und die Redundanten, das ist halt so ein bisschen merkwürdig bei denen, da ist alles Redundant, das heißt die wiederholen immer alles, also bei der Antwort auch gerne, gerne und da muss man sich so ein bisschen dran gewöhnen, aber das ist halt Redundant, die machen das nicht ohne Grund, sondern die versuchen halt, wenn eine Person ausfällt bei denen, dann kann die andere sozusagen dieses Kommando nochmal wiederholen und dann sieht man die halt hier beim Abendessen und da tauscht man sich quasi aus, naja wie ist eure Mission so gelaufen und wie macht das ihr so, wie man das halt so macht, wenn man sich so langsam beschnuppert mit fremden Besen. Nach dem Abendessen wird eine Schiffstour angeboten, das heißt die können mal so das Schiff besichtigen und die Ingenieure können auch so ein bisschen angeben und zeigen, was da so passiert und die Redundanten sind eigentlich relativ neugierig, haben natürlich auch ihre eigene Schiffstechnologie, die teilweise weiter ist als unsere eigene oder an vielen Stellen anders einfach und als sie von einem Chief Storage Engineer den Pool gezeigt bekommen, schlagen sie eben vor, dass man den einfach in den Rate 10 erweitern könnte, um die Ausfallsicherheit in so einer Deep Space Mission einfach nochmal zu erhöhen und sie haben auch eigene Speichermedien dabei, die man dafür verwenden könnte, an diesen Pool anschließen könnte und nach einer kurzen Beratung schlägt der Chief Storage Engineer einfach mal vor, das Ganze zu simulieren, bevor man das dann wirklich in echt einbaut, wenn man erst mal schauen, wie das dann aussehen würde. Und dann machen sie das, also die simulieren das Ganze, ich kann das Ganze nämlich erstmal dem System sozusagen vorgeaukeln oder so ein Dry Run machen mit dem Minus N-Komando ohne dass das dann wirklich auch ausgeführt wird und dann schaue ich mir quasi an, was hinterher dann dabei herauskommen würde. In dem Fall würde ich quasi zwei neue Platten oder Speichermedien, die habe ich hier mal Alien Discs genannt, die von den bisherigen Speichermedien zu unterscheiden, die wird man da quasi dranhängen und dazu gibt es zentpool add Kommando, das heißt, das ist eigentlich eine relativ einfache Kommando-Zeile, wo man schon so ein bisschen an dem Sprechweise oder wie das Kommando dargestellt wird, erkennen kann, was da gemeint ist. Seit ich möchte zu meinem Pool der IGA-2023 heißt, einen weiteren Spiegel hinzufügen, der aus Alien Disk 3 und Alien Disk 4 besteht und ich will das Ganze aber jetzt noch nicht machen, sondern ich will das erstmal simulieren, deswegen dieses Minus N-Komando und dann gibt eben der Pool aus, wie er dann aussehen würde, wenn wirklich dieses N nicht mehr dabei gewesen wäre. Das heißt, der Boardcomputer gibt dann aus, ich würde den IGA-2023 Pool, der auch so heißt wie das Schiff, zu der folgenden Konfiguration Updaten und dann sieht man jetzt, ist hier eine weitere Ebene hinzugefügt worden, zwar Mirror 1, Mirror 0 war schon vorher da, das heißt, diese Ebenen hier, das sind die sogenannten V-Defs, bei ZFS heißen die V-Def, Virtual-Def, unter denen findet quasi die eigentliche Redundanz statt. Wenn das Schlüsselwort nicht da ist, dann hat man einen schnöden Rate 0 Pool und der ist halt schnell weg, wenn halt ein Gerät über den Deich geht. Das heißt, auf dieser Ebene findet die Redundanz statt und alle Geräte, die sich unterhalb dieser V-Defs befinden, die führen quasi die Redundanz-Operation aus. Das heißt, hier in dem Fall ist es die Spiegel-Operation, Rate 1 und hier ist der Sonderfall, dass ich hier sogar ein Rate 10 gebaut habe. Ich habe zwei Spiegel, die mit einem Rate 0 zusammengefasst sind und intern machen die quasi ein Spiegel miteinander, also Daten, die auf eine Platte kommen, wenn auf die andere weiterkoppiert und umgekehrt. Und das eben in einem Zweierverbund hat recht hohe Performancezahlen, weil ich eben von beiden Spiegelpartnern gleichzeitig lesen kann. Schreiben ist ein bisschen langsamer, aber ich habe halt die Ausfallsicherheit, dass wenn mir eine Platte innerhalb eines von diesen beiden V-Defs ausfällt, dann habe ich sozusagen immer noch die andere innerhalb des eigenen V-Defs plus die anderen beiden in dem Spiegel V-Def. Wenn mir beide ausfallen würden innerhalb eines V-Defs, das heißt, wenn mir Medium 1 und Medium 2 ausfallen, dann ist der ganze Pool verloren. Das heißt, da ist dann keine Redundanz mehr da, die aus dem Partnerspiegel kommt. Aber ich habe zumindest mehr Möglichkeiten, hier auf Fehler zu reagieren. Also haben Sie es schon sehr schlechte Tage im Weltraum erwischt haben, wenn das passiert. Hier ist eine Frage zwischendrin. Genau, die Frage war, ist es ein Mirror und darauf aufbauen, ein Stripeset, genau, richtig. Das muss man so ein bisschen erstmal, weil Rate 10 kein offizieller Rate Level ist, aber man hat quasi den 2 Rate 1 genommen und die zusammen gestriped, dass die dann auch ein bisschen mehr Performance dann bringen. Genau, sehr schön. Das ist also, was der Boardcomputer dann ausgibt und so wollen wir es auch haben. Das heißt, jetzt können wir das Minus N wegnehmen von dem Kommando und der Chief Storage Engineer macht sich eben auf die Arbeit oder gibt sich dann dahin, dieses Interface mit diesen Alien Discs herzustellen und dann den eingebauten Poolspeicher dann auch anzuschließen. Und am Schluss gibt es nochmal ein Z-Pool Status Kommando und der Boardcomputer bestätigt dann eben auch, ja, diese Platten sind jetzt in dem Pool drin und Teil dieses Pools in der gesamten Konfiguration und fügen jetzt sowohl ihre Speicherkapazität dem Pool hinzu als auch die Redundanz, die dann eben dadurch entsteht. Und das kann ich dann immer mehr anzeigen. Und auch jeder von diesen anderen Discs hat eben diese Checksum, Lesen und Schreibe spalten und dann eben zu schauen, gibt es oft in anderen Platten Probleme. Das heißt, ich kann immer genau identifizieren, wo findet denn der Fehler statt? Hat sich der schon auf den gesamten Pool ausgebreitet oder betrifft er nur eine heißende Platte? Wenn es nur eine Platte ist oder ein Gerät, dann kann ich die auch mal austauschen ohne dass andere Geräte darin betroffen sind. Okay, dann bedankt man sich natürlich artig bei den Redundanten und freut sich auf ein weiteres Wiedersehen und dann geht die Reise weiter. Und im Tag 42, muss ich jetzt nehmen, gibt es die Entscheidung, dass man auf nahegelegene Planeten fliegen will, weil da interessante Signale von sich gibt und den möchte man jetzt genau mal unter die Lupe nehmen. Und dann fliegt man da wieder hin und dann befindet man sich im Orbit und dann merkt man schon, oh, da findet Kommunikation statt. Da sind wohl unten intelligente Wesen am Werk, die da irgendwie mit dem Raumschiff, was jetzt gerade in Orbit betreffend hat, Kontakt aufnehmen wollen und das macht man dann auch und dabei stellt sich heraus, dass es das Volk der Archivaren ist. Es ist ein generell friedliches Volk, das merkt man relativ schnell und man kommt sich relativ schnell sehr nah und man kommt eben im Gespräch und die erzählen von sich, dass sich schon sehr eine lange und ausführliche Historiendiskussion oder Dokumentation vornehmen. Das heißt, sie zeichnen im Prinzip alles auf, was sich so in deren Geschichte ereignet hat, schon sehr lange und das halt auch sehr ausführlich. Dadurch entsteht bei denen ein bisschen das Problem aktuell, was sie dann auch schildern, dass der Speicherplatz den so langsam ausgeht, weil die wirklich alles protokollieren, was so bei denen vor sich geht und den geht langsam der Speicherplatz aus, den die gar nicht mehr vollschreiben können. Und anscheinend merkt man so im Gespräch, die kennen gar nicht das Konzept der Kumpression oder der Kompremieren von Daten. Und der schief solltische Architekt unterhält sich dann ein bisschen mehr mit deren anderen Ingenieuren und erklärt dann so ein bisschen das Konzept des Datasets, was auf diesem Pool quasi aufsetzt. Das heißt, ein Dataset ist quasi eine logische Speichereinheit, habe ich es hier mal genannt, so ähnlich wie eine Partition, die ich von meiner Festplatte herkenne oder von meinem Speicherpool in dem Fall und die können den Speicher dieses Pools verwenden. Das heißt, jedes Dataset kann initial den ganzen Pool-Speicher vollschreiben bei Bedarf. Und ich kann da unbegrenzt viele Datasets erstellen. Früher, als wir in alten Zeiten noch mit DOS oder MBR unterwegs waren, da konnte man nur vier Partitionen erstellen. Dann gab es GPT, das war schon wesentlich flexibler. Und hier bei ZFS kann ich mich hier quasi total austoben. Ich kann quasi jedem statt einem Gerät oder statt einem Verzeichnis legen, ich lege einfach ein neues Dataset an, das ich dann mit bestimmten Eigenschaften ausstatte. Ich kann zum Beispiel sagen, dieses Dataset soll komprimieren und dieses andere Dataset soll nicht komprimieren oder das dritte Dataset soll eine schwächere Kompression haben als andere. Das können aber auch viele weitere Eigenschaften sein, zum Beispiel der Mountpoint. Das ist eine weitere Eigenschaft, die zu dem Dataset gehört und das Dataset dann auch quasi mit sich führt jeweils. Das Schöne ist, für den Systemadministrator oder unser Chief Storage Engineer ist der Vorteil, dass diese Datasets alle ihre Eigenschaften an ihre Kinddatasets vererben. Das heißt, ich muss das nicht jedes Mal wieder neu einstellen, sondern wenn ich einmal auf Pool-Ebene ein Dataset mit einer Eigenschaft ausgestattet habe, werden alle zukünftigen Datasets, die ich davon erstelle, auch diese Eigenschaft erben. Es sei denn, sie überschreiben diese Eigenschaft wieder. Das können sie also auch wieder. Aber ich muss nicht jedes Mal bei einem neuen Dataset wieder alles einstellen. Dann schaut man sich das mal an. Das heißt, hier habe ich jetzt quasi so ein Unterverzeichnis oder so ein Dataset für die Crew angelegt, damit die da ihre Homeverzeichnungen ablegen können. Und jetzt kann ich ein weiteres Dataset anlegen, um unsere Scans aus unserem Sensor Array einmal abzuspeichern. Das heißt, wir legen jetzt ein Dataset Scans an und man sieht hier, initial hat das wirklich die gesamte Speicherkapazität dieses Pools. Der ist natürlich unsere Rettondanten, Spende von dem Speichermedium weiter angewachsen. Und jedes Dataset initial kann, wie gesagt, den gesamten Pulspeicher verwenden, um da Daten drin abzulegen. Sehr schön. Schauen wir das Ganze nochmal an mit einem anderen Terminal. Ich kann mir jetzt anzeigen lassen, was ist denn initial die Eigenschaft dieser Property-Kompression, also dieser Einstellung Kompression. Und wenn ich initial was anlege, ein Dataset, dann hat dieses Dataset keine Kompression eingestellt. Es ist so eine Vorgabe von ZFS. Der Vorteil von Kompression ist, dass die Daten kleiner gespeichert werden. Und dann, wenn die Daten mit dazu gegriffen werden, werden die automatisch endpakt und wieder an die Daten im Hauptspeicher weitergegeben. Das heißt, die Applikationen merken gar nicht, dass das gespeichert wird. Und die sehen immer nur die endkompremierten Daten. Aber intern beim ZFS-Speichervorgang wird das quasi komprimiert und auf den Pool komprimiert abgelegt. Und jetzt kann ich eben sagen, okay, dieses Dataset mit den Scans, da wird wahrscheinlich relativ viel Daten anfallen, weil da viel Sensor-Daten natürlich abgespeichert werden im Laufe unserer Mission. Die will ich mal etwas höher komprimieren. Und da verwende ich jetzt den Kompressionsalgorithmen, wo es Z-Standard neun ist, noch relativ neu, aber in ZFS schon verfügbar. Andere Algorithmen, die man vielleicht kennt, sind G-Zip oder ja, es gibt es noch andere, die man so, man kann auch da bestimmte Levels einstellen und die lassen dann eben die Daten da drauf gespeichert werden, entsprechend schrumpfen, wenn die komprimierbar sind. Wenn ich reine Binär-Daten habe, die schon überhaupt keine Redundanz da drin haben, je nach Algorithmus, dann bringen wir das natürlich auch nichts. Und ich muss die Daten neu da drauf speichern. Ich kann nicht ein Dataset nehmen, ich muss die Kompression aktivieren und dann denken, alles ist kleiner geworden, sondern ZFS komprimiert immer nur neue Daten. Das heißt, ich müsste dieses Dataset nochmal umkopieren oder einfach die Daten nochmal kurz mit einem Touch angehen, damit ich dann ZFS dadurch sage, diese Daten jetzt bitte nochmal neu abspeichern. Aber für ein leeres Dataset, was initial dieser Eigenschaft Compression bekommt und dann da Daten reinkopiert bekommen, wie wir das dann später sehen werden da unten, dann werden natürlich alle neuen Daten sofort darauf abgelegt. Und jetzt haben wir eben neue Scans bekommen von dem Nebula 1337. Ja, und ihr seht schon, hier ist jetzt ein Unterdataset entstanden. Das heißt, ich habe unterhalb von Scans jetzt noch dieses Nebula 1337 Dataset angelegt und hier sieht man jetzt, dass diese Kompressionseigenschaft genau an dieses Dataset vererbt wurde. Deswegen steht hier als Source, in dieser Source-Spalt inherited from eager2023. Das heißt, warum sollte ich das nochmal separat eintragen wollen? Ich kann das ja von meinem Mutter oder Vater Dataset weiter vererben an das Kind Dataset. Wenn ich jetzt möchte, dass dieses Dataset keine Kompression hat aus irgendeinem Grund, dann kann ich das wieder einstellen mit ZFS Set Compression gleich off für eben diesen Dataset Namen. Die Datasets, die hängen quasi immer an dem Pool dran, also dem Pool ist immer meine größte Einheit oder meine überliegende Einheit, meine Route quasi, wie ich diese Datasets auf dem Pool anspreche. Und dann da eben kann ich eine ganz normale Unix hier aufbauen mit Slashes dazwischen. Dann kopiere ich da meine Sensor-Locks rein. Die habe ich jetzt mal aus einem virtuellen Dev-Sensor ausgenommen. Und dann sieht man schon da unten, wenn ich mir jetzt mal meine Compress-Ratio angucke von diesen Datasets, nachdem die komprimiert wurden, dann hat das schon nur noch ein Zwölftel, guck mal, das ist fiktive Wert, aber ihr merkt schon, das ist deutlich kleiner als die Ursprungsdaten. Und wie gesagt, das passiert transparent. Das heißt, da muss sich die Applikation nicht drum kümmern oder jede Anwendung, die da drauf speichert. Alles, was ZFS bekommt, wird komprimiert und abgespeichert. Und wenn es wieder geladen oder abgerufen wird, wird es automatisch endkomprimiert und an die Anwendung weitergegeben. Das finden die Archivar natürlich sehr super, genau das ist, was sie natürlich brauchen für ihr Problem. Und dann lässt sich der Chief Storage Engineer nicht nehmen, einen alten Film aus der Erde zu zitieren, nämlich Starship Troopers, möchten sie mir herwissen. Und die Archivar, na super, wie macht ihr das denn übrigens, dass ihr jetzt diesen Poolspeicher vor dem Überlauf bewahrt? Weil ihr könnt ja speichern, speichern, speichern, aber irgendwann wird euch ja dieser Poolspeicher ausgehen. Dann sagt der Chief Storage Engineer, ja, ja, ja, ja, wir haben so ein Konzept wie Quota und Reservierung da drin. Und da wollen die jetzt natürlich genauer wissen, was es damit auf sich hat. Und dann werden die eben zu dieser kleinen Minischulung auf der IGA eingeladen und wo das Ganze dann erläutert wird. Und zwar eine Quota, da kann ich wirklich festlegen, weil Initial, wie ich erwähnt hatte, lässt sich eben der gesamte Poolspeicher vollschreiben. Und jedes Data Set kann das auch, weil jedes Data Set Initial auch den gesamten Poolspeicher verwenden darf. Und Quota schränkt das eben ein, kennt man ja vielleicht MailQuota oder sonstige Quotas, die man so hat. Da kann ich zum Beispiel sagen, ich möchte jetzt einen bestimmten Data Set weniger Möglichkeiten geben. Das soll nur eine bestimmte Menge an Poolspeicher verwenden. Und damit ich nicht immer diese gesamten Riesenliste von dem ZFS-List bekommen kann ich das auch einschränken mit dem Parameter minus O. Das heißt, ich kann da sagen, was will ich denn da überhaupt angezeigt bekommen. In dem Fall sage ich minus O. Das heißt, ich kann da quasi nur die Daten ausfiltert, die man bekommen möchte. Aber hier habe ich das quasi mal gemacht, dass mir die Menge an Speicher, die Eager slash Crew Data Set zur Verfügung haben. Also die können schon eine Menge speichern, was eben gerade im Poolspeicher verfügbar ist. Das kann ich beliebig angeben, auch in der beliebigen Reihenfolge. Da ist ZFS sehr flexibel. Das kann man dann auch in irgendwelche futuristischen Reihenfolge, die können schon eine Menge speichern, was eben gerade im Pool verfügbar ist. Und jetzt sage ich, naja, die Crew, die lässt in irgendwelche komischen Holodeck-Programme laufen, die mal ein bisschen überhand nehmen. Und um das zu schützen quasi den Rest des Systems, die sollen jetzt erstmal nur ein Terabyte speichern dürfen. Das setzt sich quasi als Referenzquoter fest, für dieses Data Set. Und bei den Ref Quoters ist es so, die gelten nur auf dieses Data Set, worauf die angewendet werden. Das heißt, es gibt Ref Quoter und Quoter – da gehe ich dann gleich nochmal drauf ein – bei der Quoter wird quasi alles, was auf diesem Data Set liegt, und darunter mit von der Quoter berücksichtigt. Und wenn man das dann eben nochmal aufruft, ZFS List, dann sieht man eben, dass jetzt für dieses Data Set weniger speichert, durch diese Quoter verfügbar ist. Wenn die eben erreicht wird, dann werden keine neuen Schreibvorgänge mehr aktiviert oder nicht mehr zugelassen vom System. ZFS sperrt dann automatisch weitere Rights, lesen kann ich ganz normal weiterhin geben, irgendeinen Crewmitglied mal sagen, können wir nicht doch ein bisschen mehr Hauptspeicher bekommen oder ein bisschen mehr Plattenspeicher hier, dann geht man eben in die Verhandlung. Aber die Quoter ist wirklich stark dabei, das zu limitieren. Hier ist das Ganze für die Kind Data Set. Das heißt, ich habe das jetzt mal für die Scans gemacht, weil ich ungefähr vermute, wie viele Daten mal das Scans bekommen. Das ist schon eine Frage, ja. Die Frage war, ob man Prozentwerte angeben kann oder Hard- und Soft-Limits gibt. Das wäre noch was, was man machen sollte. Aktuell ist mir das nicht bekannt, dass es Prozentwerte gibt. Man müsste sich das selber ausrechnen, wie viel man ungefähr 20 Prozent vom Pool speichert, soll immer mehr zur Verfügung stehen oder so. Hard- und Soft-Limits gibt es auch nicht. Das heißt, wenn das Limit erreicht wird, gibt es keine Gnade, da wird nichts weiter zugelassen. Das könnte man vielleicht nochmal aufnehmen oder als Feedback an die Entwickler geben von Open-ZFS. Das sind ja isotypische Sachen, die auch in dem Altialltag auftauchen. Aktuell ist es so, dass dann knallhart alle Rides abgebrochen werden, die darüber hinausgehen. Okay. Die RAV-Quoter habe ich jetzt hier schon mal erwähnt. Das heißt, ich kann jetzt sagen, nur auf diesem Dataset soll die Quota gelten. Alle Kind-Datasets davon, die sollen davon überhaupt nicht beeindruckt werden. Die können weiterhin den gesamten Pool-Speicher nutzen. Das kann man sinnvoll nutzen, oder auch je nach Anwendungszweck auch nicht. Oder ich sage einfach, ich weiß noch gar nicht, wie viele Datasets noch in Zukunft dazukommen werden. Ich setze jetzt einfach mal eine Quota und alle, die in Zukunft dazukommen werden, erben diese Quoter natürlich wieder und bekommen man diese Quota wieder gesetzt. Es hat natürlich auch den Nachteil, dass alle Kind-Datasets, das erste Kind-Dataset, dass die Quota voll schreibt, natürlich vom weiteren Schreiben. Da muss man halt so ein bisschen schauen, wie viel Platz da ist. Aber die Eager-Crew dacht sie sich, naja, das könnte für unsere Scans eine typische Größe sein, die da an Daten anfallen. Das ist eben diese Unterscheidung. RAV-Quota, nur dieses Dataset, nicht die Kinder, oder Quota und alles andere, was auch in Zukunft noch hinzukommen wird, wann auch immer, wird diese Quota automatisch erben. Kann natürlich diese Quota auch wieder überschrieben bekommen, auch diese eine Scan, der ist ein bisschen Datenhaltiger, dem sollte man ein bisschen mehr Quota noch verpassen. Okay. Dann das Gegenstück ist die Reservierung. Also ich kann quasi Platz garantieren für einen bestimmten Datensatz oder ein Dataset. Das heißt, ich nehme vom verfügbaren Poolspeicher eine bestimmte Menge an Speicher weg, denn dann erstmal dieses Dataset bekommen kann, aber kein anderer, der noch auf diesem Pool sich drum tummelt. Und auch hier wieder die Unterscheidung. RAV-Quota, nur dieses Dataset, bekommt die Reservierung und eine reine Reservation für dieses Dataset, plus alle Kind-Datasets, die dann noch hinzukommen werden. So, dann hatte ich jetzt hier ein Beispiel, genau. Hier habe ich das mal gemacht. Ich dachte, naja, die Crew, die soll auf jeden Fall aber den Platz, den sie nun mal bekommen hat. Die haben vielleicht da auf der Erde irgendwas unterschrieben. Das sind bestimmte Menge an Speicher, die das benutzen dürfen. Und das wird denen quasi garantiert. Und dann sah ich eben ZFS Set Reservation, ein Pettarbeit von mir aus, dass die auf jeden Fall der Crew zur Verfügung steht. Und jetzt sieht man hier, dass von dem gesamten Poolspeicher plötzlich dieses ein Pettarbeit, oder wie auch immer, müsste ein Terabyte sein, eigentlich, das ist ein Pettarbeit, abgezogen wird. Das heißt, vorher hat ich 1,75 Pettarbeit, dann wird ein Pettarbeit reserviert. Und dann durch diese Reservierung garantiert der Pool, dass immer, egal wie viel, was wir gespeichert haben oder vollgeschrieben haben, dass trotzdem dieses eine Pettarbeit immer für die Crew, für dieses Dataset noch bereitgestellt wird. Deswegen wird eben das von den gesamten Poolspeicher abgezogen, dass dann alle anderen Datasets eben weniger zur Verfügung haben, um diese Garantie auch zu garantieren. Wie man so sagt. Und die Archivaren sind da sehr begeistert, weil die dann wirklich sagen können, naja, sehr gut, damit können wir ja nicht nur Platz garantieren, sondern auch eben Daten, bestimmte Mengen limitieren, wie man sagen kann, naja, wir sollen nicht so viel vollschreiben, wie unser eigener Pool dann später hergeben soll. Plus die Kompression, die macht das ganz ja noch mal kleiner. Das heißt, wir stoßen vielleicht gar nicht so früh an unsere Quota, weil wir eben die Daten, die wir bekommen oder die wir aufschreiben, gut komprimieren können und gar nicht so viel brauchen. Und wie gesagt, die muss für die Komprimierung eben ein neues Dataset anlegen, weil eben bestehende Daten, wenn ich da die Kompression aktiviere, nicht nochmal neu rekomprimiert werden, oder einfach nochmal da draufschreiben, dass dann die als neue Daten angesehen werden und das Dataset, die auch komprimiert. Also, die sind schwer begeistert davon und nehmen diese Technologien natürlich gerne entgegen und dann verabschiedet sich die Eager Crew wieder und setzt Kurs auf neue Sternensysteme und hier habe ich jetzt mal so ein Bild von einer futuristischen Antriebsstrangen genommen. Wunderschön und... gucken. Dann vergeht die Zeit eigentlich relativ ereignislos. Man fliegt so ein bisschen durch den Raum, besucht fremde Planeten. Ja, das ist manchmal auch recht langweilig. Die meisten der Crew verbringen dann die Zeit in ihren Quartieren und pflegen ihre einsame Zimmerpflanze, die sie da mitgebracht haben, als Erinnerung von zu Hause. Aber die Ruhe wehrt nicht lange, bis eines Tages nämlich eben Tag 67 anbricht und der Chief Storage Engineer ist gerade mit etwas anderem beschäftigt und kriegt über das Intercom so eine Nachricht. Brücke an Chief Storage Engineer. Ja, gibt es irgendwie ein Problem? Ja, schon. Aber das schälen sich am besten selber an auf der Brücke. Das ist schwer zu erklären, aber Sie sehen es dann schon, wenn Sie auf die Brücke kommen. Alles klar. Der Chief Storage Engineer macht es mit dem Hyperlift als erstes Folgendes. Ups, auf dem Main-View-Screen kommt eben irgendein Alien, was er sagt, all your files belong to us. Und das hat dann auch folgende Auswirkungen. Der ganze Computer ist irgendwie nicht mehr verfügbar und zeigt irgendeine komische Nachricht an, auf jedem Terminal. Und kann niemand so richtig was mit anfangen und dann machen die Aliens quasi ihre Drohung quasi wahr. Und geben sich als die Krypto Trojaniden aus. Das heißt, die haben den Eagerboard-Computer verschlüsselt und halt ohne dieses Entschlüsselungskennwort, was nur die kennen, ist kein Weiterflug möglich, weil da die ganzen Steuerungssysteme drin sind, die Lebenserhaltung und all sowas. Und die Trojaniden fordern tatsächlich 23.000 Coins als Lösegeld, kleiner Nebeneinschub. Ich habe versucht, das Space Coins zu nennen, bis ich da gemerkt hätte, die gibt es tatsächlich und ich wollte jetzt nicht so einen Endorsement machen. Also 23.000 Coins wollen ja als Lösegeld und dann würden wir uns den Schlüssel auch geben und dann können wir wieder weiterfliegen, aber die wollen halt das Geld haben, was wir nicht haben. Und die geben uns quasi 24 Stunden Bedenkzeit und jetzt haben wir halt so ein Board-Computer, der nichts richtig kann und wir den auch nicht richtig benutzen können. Aber der Chief Storage Engineer erinnert sich, ja, wir haben noch Snapshots und die werden ja relativ häufig erzeugt und wir könnten quasi das so machen, zu dem Zeitpunkt, bevor diese Infektion und so Board-Computer stattgefunden hat, zurückspringen, da wieder saubere Systeme haben und dann ganz schnell versuchen zu verschwinden. Snapshots machen quasi Folgendes, die nehmen den Zustand eines Datasets und frieren den quasi ein. Also sie machen quasi wie so eine Art Foto und dann kann man ihn wieder hinterher nachgucken anhand des Fotos, wie waren die Daten zu dieser Sternenzeit mehr oder weniger auf dem Dataset. Und so kann ich die auch wieder hervorholen. Das ist ein Punkt, innerhalb der Sternenzeit zurückspringen und mir wieder diese Daten, so wie sie zu diesem Zeitpunkt waren, wieder anzeigen lassen oder die sind dann genau zu diesem Zeitpunkt wieder. Alles andere, was dazwischen oder danach passiert ist, wird verworfen und die kehren wirklich auf diese Vergangenheitszustand zurück. Und zum Glück wird dieser Eager Pool regelmäßig mit Snapshots ausgestattet. Da läuft irgendein Prozess im Hintergrund, den nennen wir Kronjob und der macht es quasi im Hintergrund und man sollte darüber nachdenken müssen und das ist quasi eine Delta Snapshotsgeschichte. Das heißt, da wird nicht jedes Mal das ganze Dataset wieder kopiert, sondern nur die Daten, die sich auch geändert haben, werden in den neuen Snapshot übernommen. Und das verhindert quasi, dass der Pool halt irgendwann mit Snapshots überläuft. Und das beschließt man auch quasi zu machen, so als letzte Rettung. Und wie funktioniert das Ganze? Na ja, man schaut erst mal das Snapshots an, die die Eager momentan hat. Wir sehen, wir haben jetzt hier so ein Namenschema oder so ein Datum-Urzeitschema. Und dann sieht man schon, aha, mein letzter Snapshot, der ist vielleicht noch vor dem Zeitpunkt, als uns die Krypto-Trojaniden unsere Systeme verschlüsselt haben. Da können wir mal auf den Zurückspringen mit ZFS Rollback. Ich gebe dann quasi den Namen des Pools an. Natürlich den gesamten Pool, weil ich halt eben auch alles, was darunter an Datasets gelistet ist, auch quasi zurückrollen. Jeder sagt, na, da würde ich zwar Daten verlieren, aber es ist uns auf jeden Fall wichtiger, hier wieder wegzukommen, anstatt die aktuellsten Daten, die wir ähnlich entschlüsseln können, zu bekommen. Und Snapshots sind quasi von Normal-Datasets zu unterscheiden mit dem Add-Symbol. Das heißt jedes Mal, wenn ich ein Add da drin sehe, kann ich dann auch sehen, welche Snapshots ich quasi habe. Und so den kann ich dann auch wieder zurückrollen, indem ich den Snapshot-Namen angebe. Und dann machen die so ein LS, das ist ein altes, terroristisches Kommando, um Dateisystem-Inhalte aufzulisten. Und da sieht man schon, oh, ist alles wieder da. Und es ist vor allem nicht verschlüsselt. Und wir haben zwar ein paar Daten verloren, aber das ist uns auf jeden Fall wert. Wir können jetzt quasi einen neuen Snapshot machen, um mal diesen Zustand wieder festzuhalten und sagen, ich erstelle einen rekosiven Snapshot mit dem kleinen R, von meiner gesamten Eager-Pool und nennen die Halsystems clean, damit ich mich später noch dran erinnern kann, wenn er dann aussagt. Man sieht hier unten initial, der Snapshot verbraucht null bytes, weil sich ja zwischendrin nichts geändert hat und danach keine neuen Daten hinzugekommen sind. Und erst mit der Zeit wird der Snapshot von der Größe her anwachsen, je mehr Daten dann danach gespeichert werden. Also alle happy, super. Schiffsysteme wieder hergestellt, perfekt. Jetzt schnell raus hier, bevor die sich noch was anderes überlegen und unsere Daten nochmal verschlüsseln. Also dann wird es sagen, voll Gas gegeben. Und nach der Zeit merken die auch, ah, die nehmen die Verfolgen auch nicht auf. Die sind auch irgendwie proplex, dass die jetzt da rausgekommen sind. Und da gibt es noch eine Frage. Genau, die Frage war, wenn ich jetzt zurückrolle, kann ich dann trotzdem noch auf diese Daten, die verschlüsselt waren, irgendwie zurückgreifen und da irgendwie forensisch drauf zu betreiben. Die Daten werden verworfen. Das heißt, wenn ich sage, ZFS Rollback, dann wird alles, was da nachkam, dann kann ich so eine Zeitmaschine machen. Wir haben ein Dateisystem, wo ich mal zurück oder vorspringe. Ich muss quasi sagen, ja, ich will alles verwerfen. Was man natürlich machen kann, ist, man legt ein Snapshot des aktuellen Zustands an, springt dann zurück und kann diese Daten dann nochmal später untersuchen, was ja sinnvoll ist und vielleicht den Kryptokie dann rauszukriegen. Aber das muss man separat machen. ZFS Roll zurück und verwirft quasi alles, was in der Zwischenzeit da passiert ist. Ich kann auch mehrere Snapshots zurückspringen, z.B. vorletzten, sondern zudem vor, keine Ahnung, vor zwei Wochen. Aber ich muss alle Snapshots, die dazwischen liegen, auch damit verwerfen. Das heißt, ich kann da wirklich nicht sagen, spring mal zwei Wochen zurück und da wieder drei Tage voraus. Das kann das Dateisystem nicht, diese Mercherei. Da würde auch, glaube ich, kein sinnvoller Dateisystem in den Halt rauskommen. Zumindest ist so ZFS nicht entwickelt oder vom Design her aufgebaut. Also, es sind keine Verfolge als sichtbar. Die erscheinen uns nicht zu verfolgen, sehr gut. Jetzt müssen wir sicherheitshalbermal alle Systeme checken, damit wir uns nicht irgendwie den Trojaner oder was die uns da eingeschleust haben, wieder an Bord holen. Okay, also das sieht alles gut aus. Man ist jetzt wieder mit Heilerhaut davongekommen, noch mal gut gegangen. Und jetzt überlegt man sich, diese Forschungsdaten, die wir bisher gesammelt haben, die wollen wir jetzt auch irgendwie mal wieder an die Erde zurückschicken, weil wenn unser Schiff irgendwie mal irgendwo strandet, dann haben wir zwar Daten gesammelt, aber können die nie wieder unseren Erdenbürgern zurückschicken. Das heißt, die Erde soll eine regelmäßige Datensicherung von unserem Pool erhalten oder von bestimmten Inhalten unseres Pools, z.B. unseres Sensorlocks. Und das Ganze wird eben durch die Snapshots bewerkstelligt, weil die ja quasi einen Punkt innerhalb der Zeit einfrieren und danach auch nicht mehr beschrieben werden können, weil die Snapshots eben Read Only sind diese Übertragung davor, dass da irgendwelche anderen abgespaceden Leute da noch irgendwie mithören und unsere Daten abgreifen mit der Zeit. Wie kann man das machen? Naja, ich erzeuge erstmal einen Snapshot um diesen Zustand dieses Dateisystems abzuschicken und ich nenne den jetzt mal Send von mir aus. Dann liste ich mir den mal auf. Also ich habe einen Rekusiven Snapshot hier oben angelegt mit minus R, dass sich nicht nur die Scans-Krise jetzt hier darunter liegen. Da ist also noch ein Nebula dazugekommen in der Zwischenzeit. Und die haben jetzt alle diesen Snapshot bekommen, der Send heißt. Okay, und jetzt kann ich sagen ZFS Send minus Groß R, das Rekusiv, also alles, was darunter liegt, soll mitgeschickt werden. Minus V für Verbos, damit er mir anzeigt, was er da tut. Und dann wird eben wieder der Pool angegeben, slash welches Dataset, also Scans und ich habe einen Snapshot. Na ja, mein Sender Snapshot. Und den Pipen, die jetzt an so einen Alte ist, aber immer noch im Verwendung SSH, ich habe schon überlegt, wie man das nennen könnte, Secure Space, aber das Haar, es passt nicht so. Auf jeden Fall haben die Login auf der Erde, um sich da anzumelden und diese Daten dahin zu schicken und SSH macht quasi nichts anderes als das Gegenkommando zu ZFS Send, nämlich ZFS Received, das heißt die empfangen diese Daten dann darauf abgespeichert. ZFS Send und Received mag vielleicht ein bisschen merkwürdig sein, weil das Received-Kommando empfängt immer nur, liefert aber keine Acknowledgements zurück, ich habe die Daten bekommen, sondern es schluckt einfach nur alles, was bekommen, was es zugesendet bekommt. Umgekehrt, das ZFS Send-Kommando pusht quasi raus, so schnell es geht an Daten, kümmert sich aber nicht drum, dass da irgendwie eine Antwort zurückkommt und oh, die Daten habe ich nicht bekommen, sondern es wird zwischen den beiden nicht gesprochen. Das eine sendet, das andere empfängt und über diesen sicheren SSH-Kanal dazwischen, das eben gewährleistet, dass da niemand reingucken kann. Dann brauche ich natürlich SSH-Schlüssel, aber das haben die natürlich vor Abflug ausgetauscht, dass da Public Private Key Krypto zwischen Erde und Raumschiff ausgetauscht wurde im Vorfeld. Und dann mit dem V-Kommando wird eben ausgegeben, was gerade passiert und wie viele Daten schon über die Leitung wandert und wie viele Daten in diesem Snapshot enthalten sind. Das heißt, dadurch, dass ich diese Snapshots read-only habe, kann ich ja immer genau festlegen, wie groß die Daten in diesem einzelnen Snapshot sind. Und deswegen kann er hier bei der Übertragung schon genau festlegen, wie groß diese Übertragung denn sein wird. Und dann fängt er eben an, gibt eine Uhrzeit aus, mit, ich glaube, eine Sekunde kann man ausgeben, jede Sekunde gibt er dann quasi eine schöne Sache, kann man ganz gut machen. Und dann wird das eben alles übertragen und die Erde empfängt das auch und nimmt diese Daten auch entgegen und freut sich über die Forschungsdaten, die davon weiter Ferne nach Hause geschickt werden. Und ja, damit sind wir eigentlich schon am Ende der Reise. ZFSS hat natürlich noch viel mehr zu bieten, aber so mein Take-Away ist, dass man eben diese Szenarien, die waren jetzt alle zweitwas machen. Das ist keine abgespächte Technologie noch irgendwie die Entwicklung ist, sondern die ist schon, ja, viele Jahre alt sogar schon in Verwendung, ist erprobt, stabil und zuverlässig und auch in verschiedenen Systemen verfügbar. Aber dazu gibt es noch ein bisschen Lizenz-Rückfragen. Aber das ist so ein Dateisystem, das man sich auf jeden Fall mal genauer anschauen konnte, eben mit dieser Kombination, mit dem Pool zusammen, ist das eine ganz dünne Sache. Man kann den Storage auch entsprechend verwalten kann, sichern und die Redundance da drin hat, die man eben braucht, um sicher zu sein, ja, die Daten sind auch wirklich so, wie sie damals abgespeichert. Das war es von meiner Seite, wenn es noch Fragen gibt, können wir die gerne nochmal hier besprechen. Da hinten war die erste Frage. Kommt ein Mikro? Ja, dann machen wir noch. Hi, danke. Also ich kenne das bei einem Volume Set oder Subvolume Set, das man dann mit dem Defrag-Commando sagen kann, jetzt komprimieren mal die existierenden Daten mal auch. Geht es auf ZFS auch? Die Frage war, bei B3FS gibt es ein Defrag-Commando, das man verwenden kann, um die Daten sozusagen verpflichtend zu komprimieren. Ein explizites Defrag-Commando gibt es bei ZFS nicht, aber man kann da auch quasi den gleichen Data Set an und kopiert die Daten da nochmal rein. Oder ich mache ein ZFS Send und gleich wieder ein Receive auf den gleichen Pool und dadurch sind die Daten natürlich auch wieder sowohl defragmentiert, das heißt ein bisschen anderer Begriff bei ZFS, weil es da um die Free Space Map geht. Das heißt, ZFS speichert die Daten sogenannten Space Maps ab, das klingt schon sehr abgespaced. Aber da verwalten die quasi nicht, dann brauche ich ja mehr Speicherplatz, oder? Genau, natürlich, ich würde dann quasi sagen, ich kopiere das und schmeiß dann die alte Kopie weg, die halt unkomprimiert ist, weil ich hier dann nicht mehr brauche ich wieder meistens die komprimierte. Also wenn mein Pool nur 90% ausgelassen ist, dann kann ich brauche ich mehr Speicher um das machen zu können. Genau, wenn ich es nachträglich meine Daten komprimieren will. Also, wenn ich die Daten im Internet habe, was B3FS auch nutzt, da werden die Daten nicht überschrieben, sondern die werden quasi an eine neue Position gespeichert und die alte Kopie wird quasi weggeschmissen. Es sei denn nicht lege Snapshot an, dann wird auch diese alte Kopie aufgehoben. Aber durch diese kleinen Mini-Kopien und durch diese Kopie-and-Right-Operation ist der Älteste quasi weggeschmissen. Und es kann aber sein natürlich viele Datenspeicher, dass mein Pool oder diese Free-Space-Maps sehr voll laufen. Und bei 90% kann ein ZFS schon ein bisschen länger brauchen und neue freie Space-Map-Bereiche zu finden. Das heißt, da würde ich auch empfehlen am Anfang, wenn man den Pool anlegt, einfach eine Reservierung für den SysAdmin zu machen, dass etwa 10-15% des Pool-Speichers serviert sind. Und dann läuft man nicht in so Probleme rein, dass dann den Pool plötzlich langsamer wird. Also das ist so eine Strategie. Das Kopie-and-Right hat viele Vorteile, ermöglicht eben dieses rasante ZFS Snapshot und das Rollback und hat viele weitere Vorteile, weil wenn mit Zwischendrin werden da schon Schreiboperationen bei einem traditionellen Datei-System, wo ja Daten immer schrieben werden, wenn mir da der Strom ausfällt, das hat das Kommando gar nicht. Es gibt keinen Fall-System-Check-FSCK für ZFS, weil ZFS eben sagt, entweder schreibe ich die Daten an die neue Position oder ich habe es nicht mehr geschafft, die an die neue Position zu schreiben. Da habe ich aber auf jeden Fall noch die alten Daten, die ich für Kopie-and-Right hatte. Ja, hier war die nächste Frage. Wow. Ich habe irgendwie mal gelesen, dass ZFS Self-Healing ist. Können Sie da noch ein paar ZFS Self-Healing springen auf unseren Pool? Nee, der war es nicht. Da waren die Redundanten im Spiel. Ich erinnere mich noch. Ja. Genau. ZFS Self-Healing in dem Fall, ich hatte ja erwähnt, dass mit den Daten, die da abgespeichert werden, auch eine Prüfsumme gespeichert wird und diese Prüfsumme wird dann wieder ausgelesen, dann wird die Daten so gegriffen. Und das System schaut quasi, was sind denn da für Checksumme mitgespeichert und berechnet die Prüfsumme mit den Daten, die da aber auf der Platte liegen. Jetzt kann es natürlich sein, nach vielen Jahren durch verschiedene Umwelteinflüsse oder defektes Kabel, dass die Daten nicht mehr so sind, wie sie ursprünglich abgespeichert wurden. Ist vielleicht mal ein Bit von 0 auf 1 gewechselt oder irgendwas hat sich da getan und dann würde die Prüfsumme in ZFS Pool, so ein Archiv vielleicht, steuern und so was. Und jetzt greif ich die Daten wieder nach 10 Jahren auf die zu und dann berechn ich die Prüfsumme und die stimmt jetzt plötzlich nicht mehr, weil die Daten sich irgendwie geändert haben. Die Prüfsumme mit den Daten ist noch die von damals, aber die neu berechnete Prüfsumme ist eine andere. Und in dem Fall würde in der traditionellen Statusystem diese fehlerhaften Daten dadurch, dass ich hier diese Spiegel habe, schaut eben, ZFS hat denn der Spiegelpartner, die Daten auf dem Spiegelpartner, hat denn da die Prüfsumme, die erwartete Prüfsumme, die ich gerade berechnet habe. Wenn das der Fall ist, werden zwei Dinge gemacht. Einmal werden die korrekte Prüfsumme an die Anwendung weitergegeben, dass die schon mal weiterarbeiten kann und der Spiegelpartner heilt quasi durch kopierende, richtigen Prüfsumme die Daten auf dem Spiegelpartner. Das passiert im Hintergrund, wenn ich ein Systemadministrationskommando angeben, sondern das passiert quasi als Teil der Pool-Operation. Und dann gibt es ein Kommando, ZFS Scrub, also den Pool mal so richtig sauber schrubben. Da wird quasi jede Prüfsumme angeschaut von jeder Datei und die eben verglichen, ist die noch so, wie sie gerade mit dem Hauptspeicher oder mit dem von der CPU ausgegeben wird. Wenn das nicht der Fall ist, wird die entweder, aber wenn das nicht der Fall ist, dann wird es eben angezeigt, diese Datei oder diese Pfad ist fehlerhaft, den konnte ich nicht wieder herstellen und man kann das schon irgendwie dann abschätzen, oh, sind das wichtige Daten oder sind das irgendwelche, die ich mir vielleicht neu generieren kann. Bei der Redundanz hier, da würde auf jeden Fall versucht, die aus dem jeweiligen Redundanten Spiegelpartner wiederherzustellen. Und das passiert eben, dann vielleicht macht man das einmal im Monats, und währenddessen ist der Pool aber weiterhin verfügbar. Das heißt, da wird nicht irgendwie der ganze I.O. geblockt, das ein bisschen langsamer, weil dann natürlich jede Datei mal angefasst wird. Aber ich kann trotzdem weiterhin Daten drauf schreiben und wiederlesen. Das vielleicht ein bisschen langsamer, aber der Pool ist weiterhin verfügbar, während er diese Scrub-Operation macht. Und das Self-Healing passiert quasi als Teil des normalen Pool-Laufs. Weil jedes Mal, wenn ich Daten wieder speichere, dann muss ja die Prüfsumme aktualisiert werden und wenn ich es wieder lese, dann schaut, stimmt die noch mit denen überein, die da mitgespeichert wurden. Und wenn das eben nicht übereinstimmt, wird automatisch der Spiegelpartner zur Rate gezogen. Wenn die dann natürlich auch falsch sein sollten, dann hat man da wahrscheinlich ein größeres Problem. Eventuell überlegt man dann auch hier, nicht nur zwei Geräte pro V-Dev einzusetzen, sondern eben mehrere. Es ist halt noch eine Kostenfrage an der Stelle. Aber man hat natürlich die Sicherheit, wenn mir zwei Geräte ausfallen, sondern da habe ich eben noch ein Drittes. Es gibt so eine Empfehlung, da sollten nicht mehr als sieben bis neun Geräte pro V-Dev aktiviert sein. Man kann natürlich mehr machen, aber irgendwann ist halt da auch irgendwann ein Limit erreicht und intern ist dann so viel mit Verwaltung zu tun, dass dann einfach ZFS intern dann nicht mehr weiterkommt. Dann lieber einen neuen V-Dev machen. Ich kann da noch einen Mirror 2, 3, 4 und so weiter machen oder einen komplett neuen Spiegel aus diesen Speichermedien bauen. Das ist ja auch nicht verboten. Man kann da mehrere Pools anlegen. Ja, da geht es weiter. Da wollte ich nur anmerken, dass mit dem Self-Healing ist ja schön, aber das Wichtigste aus meiner Sicht ist, dass man Fehler bemerkt. Also wenn beide Checkstommer nicht stimmen, dann kriegt man einen IO-Aro. Wenn ich den Datei kopiere, dann bricht der Vorgang ab. Auf meinem X4 macht er einfach weiter und wenn ich dann, dann muss ich selber, wenn ich einen MD5-Sum mache, dann sehe ich, oh, falsches MD5-Sum. Und das ist meiner Meinung nach das Wichtigste, dass man nur einen Device hat, dass man feststellt, hey, ich habe eine Korruption. Ich sollte lieber meinen Backup holen und vom Backup das Restoren, weil RAID ist ja auch kein Backup. Das muss man auch immer dazusagen. RAID ist kein Backup. Auch dieses Snapshots natürlich, wenn die auf meinem Pool liegen und der Pool geht mehr Hops, dann, wenn ich die nirgendwo mal weggesendet habe oder ich kann die ja auch kopieren, dann sind die trotzdem Hops. Dann haben in unserer Datei-System, dass die auch die Fehler anzeigen oder teilweise auf Datei-Ebene schon anzeigen. Diese Datei ist jetzt korrumpiert worden und dann soll der Systematministerat eben entscheiden, ist die, sozusagen, kann man die aus dem Backup wiederherstellen oder ist die vernachlässigbar, weil das vielleicht irgendein Kompilatefakt ist, dass man wiederherstellen kann. Aber es ist gut zu wissen, dass es überhaupt ein Fehler aufgetreten ist. Noch besser ist es, dass man eben genug Rett und Danzen vor sich hält. Deswegen, wenn ihr jetzt anfangen, mit ZFS ein bisschen zu spielen, dann würde ich euch auf jeden Fall empfehlen, mal mit Spiegel anzufangen, weil man da eben auch bestimmte Effekte sehen kann, eben dieses Selbstteilung. Und meine Spiegel kann ich auch sagen, ich mache in-place-upgrade. Das heißt, ich habe diese zwei, ich mache nur dieses Medium 1 und 2. Und dann kann ich sagen, oh, mir geht der Plattenplatz aus. Ich muss jetzt aber den Pool nicht komplett runterfahren, bau eine Größe rein. Lasst es resynchronisieren, weil natürlich die Daten immer auf beiden Spiegelpaarden an die gleichen sein müssen. Dann, wenn das abgeschlossen ist, dann ziehe ich die nächste Platte raus, bau die Größe rein, lasse die wieder synchronisieren. Und derzeit kann natürlich der Pool weiter arbeiten mit dieser einen Platte. Und ich habe dann sozusagen im Betrieb meinen Pool anwachsen lassen. Das ist so eine Möglichkeit. Natürlich sollte mir an einem schlechten Tag dann nicht, während diese eine Platte in dem Pool gerade darstellen, während die andere gezogen ist, diese eine Platte, in die ich gerade hoppskehne. Deswegen sollte man vielleicht hier wirklich drei Medien pro WDF haben, dass man sozusagen noch eine weitere Platte als Redundanz hat. Aber das muss man immer so ein bisschen abwägen. Speicherkapazität, Redundanz und eben auch Kosten ist so ein Faktor da drin. Aber man kann mit ZFS einfach mal klein anfangen. Wir haben ja gesehen, wir haben mit dem Spiegel gestartet und haben den zu einem Rate 10 erweitert. Es gibt das ZFS eben her, dass man das im Betrieb machen kann und das Ganze nochmal stoppen, datensichern, neuen Pool anlegen. Das kann man alles im Betrieb machen und die Leute können weiterhin damit arbeiten, Dateien lesen und schreiben. Gibt es noch weitere Fragen? Ja, hier vorne. Genau, die Frage war, wo denn die Snapshot-Daten landen? Die Snapshot-Daten, die sind Teil des Pools. Die liegen damit drauf. Die sind ja quasi Abbilder und das heißt, mit jedem Copy and Write, die schreibt eine Datei, wird eine neue Kopie angelegt und diese Daten, also nicht eine komplette Kopie, sondern nur das Delta, was sich geändert hat in dieser Datei und mit dem Nicht-Snapshot würde quasi diese alte Kopie irgendwann weggeschmissen. Die braucht man nicht mehr. Wenn ich aber ein Snapshot anlege, sage ich, ich will diesen Zustand einfrieren und dann behalte ich eben diese alte Kopie vor. Da stehen aber auch nur drin so und so viel Bytes, an dem und der Uhrzeit, die sind aber fest. Das heißt, die kann ich nicht nochmal verändern. Die sind read-only, bis ich eben auf diesen Zustand zurückfalle oder auf einen Zustand weiter zurück gehe in meiner Historie und dann eben diesen alten Snapshot verwerfert. Das heißt, diesen Mitteil des Pools gespeichert und hängt dann an jeweils einem Dataset dran, von dem so ursprünglich abstammt. Das hat man hier gesehen. Ich habe meine Logs gesnapshotted und diesen Teil dieses Logs und Datasets auf die Snapshots verloren. Da kann man dann auch sagen, warne mich bitte vorher, es gibt auch ein ZFS-Destroy-Kommando natürlich und da kann man auch ein Verbos-Kommando einfügen oder ein Minus-N-Kommandos und Dry Run, wie wir das bei dem Z-Polat hier gesehen haben. Das ist ja so, zeig mir mal bitte, was du da machen würdest, bevor du es wirklich ausführst. Und dann sieht man manchmal, oh, da hängt ja noch Snapshots dran. Die wollte ich vielleicht aufheben und dann kommt man dann so ein bisschen in diese ZFS-Welt rein, wenn man mal so ein bisschen sieht, was es für Features gibt und die man dann auch irgendwie sinnvoll einsetzen kann. Ich kann zum Beispiel sagen, ich erzeug ein Snapshot, schicke mir den an meinen eigenen Pool und habe damit automatisch eine Kopie von diesem Dataset angelegt, zu dem Zeitpunkt, die dieses Dataset hatte, als es vor zwei Monaten, zwei Jahren, fünf Wochen, wann auch immer angelegt wurde. Also ich arbeite viel und dann muss man das Labor einmal einrichten. Na ja, was mache ich? Ich lege einmal die Dateien an auf meinem ZFS, breit wie so vor, wie das die Dozenten haben möchten. Und dann gehen drei Semester oder mehrere Semester ins Land oder ich sage ein Semester, die Studenten arbeiten da drauf, legen Daten an und am Ende des Semesters sage ich, ZFS Rollback und ich habe alles wieder so in dem Zustand, wie ich es mal am Anfang des Semesters war, so wie ich es eingerichtet habe. Und was auch immer die da drin erzeugt haben, dann mache ich den Zustand, will ich behalten, dann mache ich eben ZFS Send dieses Datasets, was ich gesnapschottet habe und habe dann den Zustand am Ende des Semesters nochmal gesichert, wenn der Professor nochmal draufgucken möchte oder irgendwas. Und ich habe das quasi innerhalb von Sekunden wieder hergestellt zu dem Zustand, den ich damals hatte. Aber wenn die bösen Krypto-Allienz kommen, dann sind auch die Snapshots gleich mit? Ne, genau, das ist nochmal die Frage zu dieser Krypto-Allien-Geschichte. Also wenn jetzt die Kryptotrojaner die Snapshots, die ich, das wird nicht automatisch gemacht, das muss man sich quasi einrichten, als kleinen Groundjob, dass die automatisch angelegt werden. Wenn die jetzt meine Platte verschlüsseln, dann die Snapshots, die sind immer Read-Only, das heißt, die kann ich gar nicht mehr beschreiben, die kann ich nicht verändern. Das heißt, ich kann dann immer mit einem Rescue-System da dran gehen, das habe ich jetzt hier nicht so ausführlich erwähnt, aber ich kann dann immer sagen, ZFS Rollback zu einem Stand vor der Infektion oder bei einem Virus oder was auch immer es gibt und spring dann zu einem Zustand zurück, der ja noch Heile war oder der noch nicht diese Fehler hatte. Das kann auch ein fehlgeschlagenes Systemupdate sein oder ein Paketupgrade, was eine neue Version bringt, die mein Webshop nicht mehr laufen lässt oder irgendwas, dann spring ich eben auf den Zustand zurück vor diesem Update oder vor dem System Schaden, was auch immer eingetreten ist und habe dann wieder den Zustand von damals verliere natürlich die Daten, die dazwischen drin angelegt wurden, aber meistens ist mir der saubere Zustand dann sicherer, als diese Krypto-Daten zu haben. Und so kann man sich ganz einfach retten, indem man das regelmäßig macht und es gibt auch so Backup-Tools, die dann quasi noch so einem Großvater-Vater-Sohn-Prinzip, die Snapshots dazwischen dann auch wieder löschen. Das heißt, die machen dann aus täglichen Wöchentliche, aus wöchentlichen Monatliche und aus monatlichen dann jährliche Snapshots und alles was dazwischen drin wird dann quasi weggelöscht und haben halt so eine riesen Snapshot-Liste. Aber haben wir dann trotzdem diese Möglichkeit weiter zurückzurollen. Okay, alles klar, dann vielen Dank. Ich hoffe, es hat ein bisschen gefallen mit den ganzen abgespaceden Bildern und noch viel Spaß auf der intergalaktischen Erfahrungsreise.