{"id":83582,"date":"2020-06-01T19:42:21","date_gmt":"2020-06-01T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost"},"modified":"2020-06-01T19:42:21","modified_gmt":"2020-06-01T17:42:21","slug":"osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Grundlagen von ZFS: Speicher- und Leistungsmanagement","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Grundlagen
\n
\nIn diesem Fr\u00fchling haben wir bereits einige Einf\u00fchrungsthemen besprochen, zum Beispiel, wie man die Geschwindigkeit Ihrer Laufwerke \u00fcberpr\u00fcft<\/a><\/noindex> und was RAID ist<\/a><\/noindex>. Im zweiten haben wir sogar versprochen, die Leistung verschiedener Multi-Disk-Topologien in ZFS weiter zu untersuchen. Dies ist ein Dateisystem der n\u00e4chsten Generation, das jetzt \u00fcberall implementiert wird: von Apple<\/a><\/noindex> bis Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nTja, heute ist der passendste Tag, um ZFS kennenzulernen, liebe Leser. Wissen Sie einfach, dass es nach einer bescheidenen Einsch\u00e4tzung des Entwicklers von OpenZFS, Matt Arents, \u201ewirklich kompliziert ist\u201c.<\/p>\n

Aber bevor wir zu den Zahlen kommen \u2013 und die werden kommen, versprochen \u2013 zu allen Variationen der acht Laufwerk-Konfigurationen in ZFS, m\u00fcssen wir \u00fcber das sprechen, als<\/i> wie ZFS \u00fcberhaupt Daten auf der Festplatte speichert.<\/p>\n

Zpool, vdev und device<\/h1>\n

\n\"Grundlagen
\nDieses Diagramm des vollst\u00e4ndigen Pools umfasst drei unterst\u00fctzende vdevs, jeweils eines aus jeder Klasse, und vier f\u00fcr RAIDz2.<\/i><\/p>\n

\"Grundlagen
\nNormalerweise gibt es keinen Grund, einen Pool aus nicht \u00fcbereinstimmenden Typen und Gr\u00f6\u00dfen von vdevs zu erstellen \u2013 aber wenn Sie m\u00f6chten, steht nichts dem im Weg.<\/i><\/p>\n

Um das Dateisystem ZFS wirklich zu verstehen, muss man sich die tats\u00e4chliche Struktur genauer ansehen. Erstens kombiniert ZFS die traditionellen Ebenen der Volume- und Dateisystemverwaltung. Zweitens verwendet es einen transaktionalen Mechanismus f\u00fcr das Copy-on-write. Diese Merkmale bedeuten, dass das System strukturell sehr anders ist als herk\u00f6mmliche Dateisysteme und RAID-Arrays. Der erste Satz grundlegender Bausteine zum Verst\u00e4ndnis: es ist der Speicherpool (zpool), das virtuelle Ger\u00e4t (vdev) und das reale Ger\u00e4t (device).<\/p>\n

zpool<\/h3>\n

\nDer Speicherpool zpool ist die h\u00f6chste Struktur in ZFS. Jeder Pool enth\u00e4lt ein oder mehrere virtuelle Ger\u00e4te. Jedes davon enth\u00e4lt wiederum ein oder mehrere reale Ger\u00e4te (device). Virtuelle Pools sind autarke Bl\u00f6cke. Ein physischer Computer kann zwei oder mehr separate Pools enthalten, aber jeder ist v\u00f6llig unabh\u00e4ngig von den anderen. Pools k\u00f6nnen keine virtuellen Ger\u00e4te gemeinsam nutzen.<\/p>\n

Die Redundanz von ZFS befindet sich auf der Ebene der virtuellen Ger\u00e4te, nicht auf der Ebene der Pools. Auf der Ebene der Pools gibt es absolut keine Redundanz \u2013 wenn ein vdev-Laufwerk oder ein spezieller vdev verloren geht, geht der gesamte Pool mit ihm verloren.<\/p>\n

Moderne Speicherpools k\u00f6nnen den Verlust des Caches oder des Journals des virtuellen Ger\u00e4ts \u00fcberstehen \u2013 obwohl sie m\u00f6glicherweise eine kleine Menge an unsauberen Daten verlieren, wenn sie das vdev-Journal w\u00e4hrend eines Stromausfalls oder Systemausfalls verlieren.<\/p>\n

Es gibt ein weit verbreitetes Missverst\u00e4ndnis, dass ZFS \"Datenstreifen\" (Stripes) \u00fcber den gesamten Pool geschrieben werden. Das ist nicht korrekt. Zpool ist keineswegs ein lustiger RAID0, es ist eher lustig JBOD<\/a><\/noindex> mit einem komplexen variablen Verteilungssystem.<\/p>\n

In der Regel werden die Aufzeichnungen entsprechend dem verf\u00fcgbaren freien Speicherplatz auf die verf\u00fcgbaren virtuellen Ger\u00e4te verteilt, sodass theoretisch alle gleichzeitig gef\u00fcllt werden. In neueren Versionen von ZFS wird die aktuelle Nutzung (Auslastung) des vdev ber\u00fccksichtigt \u2013 wenn ein virtuelles Ger\u00e4t signifikant st\u00e4rker belastet ist als ein anderes (zum Beispiel aufgrund von Lesevorg\u00e4ngen), wird es vor\u00fcbergehend f\u00fcr Schreibvorg\u00e4nge \u00fcbersprungen, obwohl der h\u00f6chste Anteil an freiem Speicherplatz verf\u00fcgbar ist.<\/p>\n

Der Auslastungserkennungsmechanismus, der in moderne ZFS-Schreibverteilungsmethoden integriert ist, kann die Verz\u00f6gerung verringern und die Bandbreite w\u00e4hrend Zeiten ungew\u00f6hnlich hoher Last erh\u00f6hen \u2013 aber das ist kein Freibrief<\/i> f\u00fcr unbeabsichtigtes Mischen langsamer HDDs und schneller SSDs in einem Pool. Ein solch unausgewogener Pool wird dennoch mit der Geschwindigkeit des langsamsten Ger\u00e4ts arbeiten, als w\u00e4re er ausschlie\u00dflich aus solchen Ger\u00e4ten zusammengesetzt.<\/p>\n

vdev<\/h3>\n

\nJeder Speicherpool besteht aus einem oder mehreren virtuellen Ger\u00e4ten (virtual device, vdev). Jedes vdev umfasst wiederum ein oder mehrere physische Ger\u00e4te. Die meisten virtuellen Ger\u00e4te werden zur einfachen Datenspeicherung verwendet, es gibt jedoch mehrere unterst\u00fctzende vdev-Klassen, einschlie\u00dflich CACHE, LOG und SPECIAL. Jeder dieser vdev-Typen kann eine der f\u00fcnf Topologien haben: Einzelger\u00e4t (single-device), RAIDz1, RAIDz2, RAIDz3 oder Spiegel (mirror).<\/p>\n

RAIDz1, RAIDz2 und RAIDz3 sind spezielle Varianten dessen, was Old-School-Nutzer als Double Parity RAID bezeichnen w\u00fcrden. 1, 2 und 3 beziehen sich darauf, wie viele Parit\u00e4tsbl\u00f6cke f\u00fcr jeden Datenstreifen zugewiesen sind. Anstelle von einzelnen Laufwerken zur Sicherstellung der Parit\u00e4t verteilt RAIDz virtuelle Ger\u00e4te diese Parit\u00e4t gleichm\u00e4\u00dfig auf die Laufwerke. Ein RAIDz-Array kann so viele Laufwerke verlieren, wie es Parit\u00e4tsbl\u00f6cke hat; wenn es ein weiteres verliert, ist es ausgefallen und nimmt den Speicherpool mit sich.<\/p>\n

In Spiegel-virtuellen Ger\u00e4ten (mirror vdev) wird jeder Block auf jedem Ger\u00e4t im vdev gespeichert. Obwohl die am h\u00e4ufigsten verwendeten Spiegel doppelt sind (two-wide), kann ein Spiegel eine beliebige Anzahl von Ger\u00e4ten haben \u2013 in gro\u00dfen Installationen werden oft dreifache Spiegel verwendet, um die Leseleistung und Ausfallsicherheit zu erh\u00f6hen. Ein vdev-Spiegel kann jeden Ausfall \u00fcberstehen, solange mindestens ein Ger\u00e4t im vdev weiterhin funktioniert.<\/p>\n

Einfache vdevs sind von Natur aus gef\u00e4hrlich. Ein solches virtuelles Ger\u00e4t wird keinen Ausfall \u00fcberstehen \u2013 und wenn es als Speicher oder spezielles vdev verwendet wird, f\u00fchrt ein Ausfall zu einem Verlust des gesamten Pools. Seien Sie hier sehr, sehr vorsichtig.<\/p>\n

Virtuelle Ger\u00e4te CACHE, LOG und SPECIAL k\u00f6nnen in einer beliebigen der oben genannten Topologien erstellt werden \u2013 aber denken Sie daran, dass der Verlust eines virtuellen Ger\u00e4ts SPECIAL den Verlust des Pools bedeutet, daher wird eine redundante Topologie dringend empfohlen.<\/p>\n

Ger\u00e4t<\/h3>\n

\nWahrscheinlich der einfachste zu verstehende Begriff in ZFS \u2013 es handelt sich um ein Blockger\u00e4t mit zuf\u00e4lligem Zugriff. Denken Sie daran, dass virtuelle Ger\u00e4te aus einzelnen Ger\u00e4ten bestehen und der Pool aus virtuellen Ger\u00e4ten besteht.<\/p>\n

Festplatten \u2013 sowohl magnetische als auch SSDs \u2013 sind die am h\u00e4ufigsten verwendeten Blockger\u00e4te, die als Bausteine f\u00fcr vdevs eingesetzt werden. Allerdings ist jedes Ger\u00e4t, das einen Deskriptor in \/dev hat, geeignet \u2013 sodass ganze Hardware-RAID-Arrays als einzelne Ger\u00e4te verwendet werden k\u00f6nnen.<\/p>\n

Eine einfache Raw-Datei ist eines der wichtigsten alternativen Blockger\u00e4te, aus denen ein vdev aufgebaut werden kann. Testpools aus Sparse-Dateien<\/a><\/noindex>\u00a0sind eine sehr praktische M\u00f6glichkeit, um Poolbefehle zu testen und zu sehen, wie viel Speicher im Pool oder virtuellen Ger\u00e4t dieser Topologie verf\u00fcgbar ist.<\/p>\n

\"Grundlagen
\nSie k\u00f6nnen in nur wenigen Sekunden einen Testpool aus sparsen Dateien erstellen \u2013 vergessen Sie nicht, sp\u00e4ter den gesamten Pool und seine Komponenten zu l\u00f6schen.<\/i> <\/p>\n

Angenommen, Sie m\u00f6chten einen Server mit acht Festplatten einrichten und planen, 10 TB (~9300 GiB) Festplatten zu verwenden \u2013 aber Sie sind sich nicht sicher, welche Topologie am besten zu Ihren Bed\u00fcrfnissen passt. Im obigen Beispiel erstellen wir in nur wenigen Sekunden einen Testpool aus sparsen Dateien \u2013 und wissen nun, dass ein RAIDz2 vdev mit acht 10 TB Festplatten 50 TiB nutzbaren Speicherplatz bietet.<\/p>\n

Eine weitere spezielle Ger\u00e4tekategorie sind SPARE (Ersatzger\u00e4te). Hot-Swap-f\u00e4hige Ger\u00e4te geh\u00f6ren im Gegensatz zu herk\u00f6mmlichen Ger\u00e4ten dem gesamten Pool und nicht einem einzelnen virtuellen Ger\u00e4t. Wenn ein vdev im Pool ausf\u00e4llt und ein Ersatzger\u00e4t an den Pool angeschlossen und verf\u00fcgbar ist, wird es automatisch dem betroffenen vdev zugeordnet.<\/p>\n

Nachdem das Ersatzger\u00e4t mit dem betroffenen vdev verbunden ist, beginnt es, Datenkopien oder -rekonstruktionen zu erhalten, die auf dem fehlenden Ger\u00e4t vorhanden sein sollten. Im traditionellen RAID wird dies als Wiederherstellung (rebuilding) bezeichnet, w\u00e4hrend es in ZFS \"Wiederherstellung von Redundanz\" (resilvering) genannt wird.<\/p>\n

Es ist wichtig zu beachten, dass Ersatzger\u00e4te defekte Ger\u00e4te nicht dauerhaft ersetzen. Sie sind lediglich eine vor\u00fcbergehende L\u00f6sung, um die Zeit zu verk\u00fcrzen, w\u00e4hrend ein vdev degradierbar ist. Nachdem der Administrator das ausgefallene Ger\u00e4t im vdev ersetzt hat, erfolgt die Wiedereinrichtung der Redundanz auf das permanente Ger\u00e4t, und das SPARE-Ger\u00e4t wird vom vdev getrennt und kehrt zu seiner Funktion als Ersatzger\u00e4t f\u00fcr den gesamten Pool zur\u00fcck.<\/p>\n

Datens\u00e4tze, Bl\u00f6cke und Sektoren<\/h1>\n

\nDer n\u00e4chste Baustein, den es auf unserer Reise durch ZFS zu verstehen gilt, bezieht sich weniger auf die Hardware als darauf, wie die Daten selbst organisiert und gespeichert werden. Wir \u00fcberspringen hier einige Ebenen \u2013 wie z.B. metaslab \u2013, um es nicht mit Details zu \u00fcberfrachtet, w\u00e4hrend wir das Gesamtverst\u00e4ndnis der Struktur bewahren.<\/p>\n

Datensatz (dataset)<\/h3>\n

\n\"Grundlagen
\nWenn wir zum ersten Mal einen Datensatz erstellen, zeigt er den gesamten verf\u00fcgbaren Speicherplatz des Pools an. Dann setzen wir ein Kontingent fest \u2013 und \u00e4ndern den Einh\u00e4ngepunkt. Magie!<\/i> <\/p>\n

\"Grundlagen
\nZvol ist gr\u00f6\u00dftenteils einfach ein Datensatz, der seiner Dateisystemschicht entledigt ist, die wir hier durch ein v\u00f6llig normales Dateisystem wie ext4 ersetzen.<\/i> <\/p>\n

Der ZFS-Datensatz ist in etwa mit einem standardm\u00e4\u00dfig montierten Dateisystem vergleichbar. Wie ein gew\u00f6hnliches Dateisystem scheint es auf den ersten Blick \"einfach nur ein weiterer Ordner\" zu sein. Doch genau wie bei herk\u00f6mmlichen gemounteten Dateisystemen hat jeder ZFS-Datensatz seine eigenen grundlegenden Eigenschaften.<\/p>\n

Zun\u00e4chst kann einem Datensatz ein festgelegtes Kontingent zugewiesen werden. Wenn Sie zfs set quota=100G poolname\/datasetname<\/code>, dann k\u00f6nnen Sie nichts in den gemounteten Ordner schreiben \/poolname\/datasetname<\/code> was \u00fcber 100 GiB hinausgeht.<\/p>\n

Haben Sie die Anwesenheit \u2013 und Abwesenheit \u2013 der Schr\u00e4gstriche zu Beginn jeder Zeile bemerkt? Jeder Datensatz hat seinen Platz sowohl in der ZFS-Hierarchie als auch in der Hierarchie des System-Mounts. In der ZFS-Hierarchie gibt es keinen f\u00fchrenden Schr\u00e4gstrich \u2013 Sie beginnen mit dem Namen des Pools und dann dem Pfad von einem Datensatz zum n\u00e4chsten. Zum Beispiel, pool\/parent\/child<\/code> f\u00fcr einen Datensatz mit dem Namen child<\/code> unter dem \u00fcbergeordneten Datensatz parent<\/code> in einem Pool mit dem kreativen Namen pool<\/code>.<\/p>\n

Standardm\u00e4\u00dfig entspricht der Mountpunkt des Datensatzes seinem Namen in der ZFS-Hierarchie, mit einem Schr\u00e4gstrich am Anfang \u2013 der Pool namens pool<\/code> wird als \/pool<\/code>gemountet, der Datensatz parent<\/code> wird in \/pool\/parent<\/code>gemountet, und der untergeordnete Datensatz child<\/code> wird in \/pool\/parent\/child<\/code>gemountet. Der systematische Mountpunkt des Datensatzes kann jedoch ge\u00e4ndert werden.<\/p>\n

Wenn wir angeben, zfs set mountpoint=\/lol pool\/parent\/child<\/code>, dann wird der Datensatz pool\/parent\/child<\/code> im System als \/lol<\/code>.<\/p>\n

gemountet. Neben Datens\u00e4tzen m\u00fcssen wir auch Volumes (zvols) erw\u00e4hnen. Ein Volume ist in etwa mit einem Datensatz vergleichbar, es gibt jedoch tats\u00e4chlich kein Dateisystem darin \u2013 es handelt sich einfach um ein Blockger\u00e4t. Sie k\u00f6nnen beispielsweise ein zvol<\/code> mit dem Namen mypool\/myzvol<\/code>, dann es mit dem Dateisystem ext4 formatieren und dieses Dateisystem dann mounten \u2013 jetzt haben Sie ein ext4-Dateisystem, das alle Sicherheitsfunktionen von ZFS unterst\u00fctzt! Das mag auf einem Computer albern erscheinen, macht aber viel mehr Sinn als Backend bei der Exportierung eines iSCSI-Ger\u00e4ts.<\/p>\n

Bl\u00f6cke<\/h3>\n

\n\"Grundlagen
\nEine Datei besteht aus einem oder mehreren Bl\u00f6cken. Jeder Block wird auf einem virtuellen Ger\u00e4t gespeichert. Die Blockgr\u00f6\u00dfe entspricht normalerweise der Parameter recordsize<\/b>, kann jedoch auf 2^ashift<\/b>reduziert werden, wenn er Metadaten oder eine kleine Datei enth\u00e4lt.<\/i><\/p>\n

\"Grundlagen
\nWir meinen wirklich, tats\u00e4chlich<\/b> dass es einen enormen Leistungseinbruch gibt, wenn ashift zu klein eingestellt wird.<\/i><\/p>\n

Im ZFS-Pool werden alle Daten, einschlie\u00dflich Metadaten, in Bl\u00f6cken gespeichert. Die maximale Blockgr\u00f6\u00dfe f\u00fcr jedes Datenset wird in der Eigenschaft \" recordsize<\/code> (Aufzeichnungsgr\u00f6\u00dfe) festgelegt. Die Aufzeichnungsgr\u00f6\u00dfe kann variieren, beeinflusst jedoch nicht die Gr\u00f6\u00dfe oder Position bereits in das Datenset geschriebenen Bl\u00f6cke \u2013 sie gilt nur f\u00fcr neue Bl\u00f6cke beim Schreiben.<\/p>\n

Sofern nicht anders festgelegt, betr\u00e4gt die aktuelle Standardaufzeichnungsgr\u00f6\u00dfe 128 KiB. Dies ist eine Art schwieriger Kompromiss, bei dem die Leistung in den meisten F\u00e4llen weder ideal noch schlimm sein wird. Recordsize<\/code> kann auf einen beliebigen Wert von 4K bis 1M festgelegt werden (mit zus\u00e4tzlichen Einstellungen recordsize<\/code> kann es noch gr\u00f6\u00dfer eingestellt werden, aber das ist selten eine gute Idee).<\/p>\n

Jeder Block bezieht sich nur auf die Daten einer einzelnen Datei \u2013 Sie k\u00f6nnen nicht zwei verschiedene Dateien in einen Block stecken. Jede Datei besteht aus einem oder mehreren Bl\u00f6cken, abh\u00e4ngig von der Gr\u00f6\u00dfe. Ist die Dateigr\u00f6\u00dfe kleiner als die Aufzeichnungsgr\u00f6\u00dfe, wird sie in einem kleineren Block gespeichert \u2013 zum Beispiel belegt ein 2 KiB gro\u00dfer Block mit einer Datei nur einen 4 KiB gro\u00dfen Sektor auf der Festplatte.<\/p>\n

Volumes vom Typ zvol haben keine Eigenschaft recordsize<\/code>\u00a0\u2013 stattdessen haben sie eine \u00e4quivalente Eigenschaft volblocksize<\/code>.<\/p>\n

Sektoren<\/h3>\n

\nDer letzte, grundlegendste Baustein \u2013 der Sektor. Dies ist die kleinste physikalische Einheit, die von dem zugrunde liegenden Ger\u00e4t geschrieben oder gelesen werden kann. Jahrzehntelang wurden in den meisten Festplatten Sektoren mit 512 Bytes verwendet. In letzter Zeit sind die meisten Festplatten auf 4 KiB-Sektoren eingestellt, und in einigen \u2013 insbesondere SSDs \u2013 sogar auf 8 KiB oder mehr.<\/p>\n

Im ZFS-System gibt es eine Eigenschaft, die es erm\u00f6glicht, die Sektorgr\u00f6\u00dfe manuell festzulegen. Diese Eigenschaft ashift<\/code>. Es ist etwas verwirrend, dass ashift eine Potenz von zwei ist. Zum Beispiel ashift=9<\/code> bedeutet eine Sektorgr\u00f6\u00dfe von 2^9 oder 512 Bytes.<\/p>\n

ZFS fragt das Betriebssystem nach detaillierten Informationen zu jedem Blockger\u00e4t, wenn es in ein neues vdev hinzugef\u00fcgt wird, und stellt theoretisch automatisch den ashift entsprechend diesen Informationen ein. Leider l\u00fcgen viele Festplatten \u00fcber ihre Sektorgr\u00f6\u00dfe, um die Kompatibilit\u00e4t mit Windows XP zu wahren (das nicht in der Lage war, Festplatten mit anderen Sektorgr\u00f6\u00dfen zu erkennen).<\/p>\n

Das bedeutet, dass es f\u00fcr den ZFS-Administrator dringend empfohlen wird, die tats\u00e4chliche Sektorgr\u00f6\u00dfe seiner Ger\u00e4te zu kennen und manuell einzustellen ashift<\/code>. Wenn ein zu kleiner ashift eingestellt ist, steigt die Anzahl der Lese-\/Schreiboperationen astronomisch an. So bedeutet das Schreiben von 512-Byte-\"Sektoren\" in einen tats\u00e4chlichen Sektor von 4 KiB, dass zuerst der erste \"Sektor\" geschrieben, dann der 4 KiB-Sektor gelesen, dieser mit dem zweiten 512-Byte-\"Sektor\" ge\u00e4ndert und dann zur\u00fcck in den neuen 4 KiB-Sektor geschrieben werden muss, und so weiter f\u00fcr jede Aufzeichnung.<\/p>\n

In der realen Welt hat dieser Strafen einen gro\u00dfen Einfluss auf die Samsung EVO Solid-State-Laufwerke, f\u00fcr die gelten muss ashift=13<\/code>, aber diese SSDs l\u00fcgen \u00fcber ihre Sektorgr\u00f6\u00dfe, weshalb standardm\u00e4\u00dfig eingestellt wird ashift=9<\/code>. Wenn ein erfahrener Systemadministrator diesen Parameter nicht \u00e4ndert, arbeitet diese SSD , als Muster, die verwenden<\/i> wie eine herk\u00f6mmliche magnetische HDD.<\/p>\n

Im Vergleich dazu gibt es bei einer zu gro\u00dfen Gr\u00f6\u00dfe ashift<\/code> praktisch keinen Nachteil. Es gibt keinen echten Leistungsabfall, und der Anstieg des nicht genutzten Raums ist unendlich gering (oder null, wenn die Kompression aktiviert ist). Daher empfehlen wir nachdr\u00fccklich sogar f\u00fcr Festplatten, die tats\u00e4chlich 512-Byte-Sektoren verwenden, einzustellen ashift=12<\/code> oder sogar ashift=13<\/code>, um sicher in die Zukunft zu blicken.<\/p>\n

Eigenschaft ashift<\/code> wird f\u00fcr jedes virtuelle Ger\u00e4t vdev eingestellt, und nicht f\u00fcr den Pool<\/i>, wie viele f\u00e4lschlicherweise denken \u2013 und wird nach der Einstellung nicht mehr ge\u00e4ndert. Wenn Sie versehentlich ashift<\/code> beim Hinzuf\u00fcgen eines neuen vdevs zum Pool durcheinandergebracht haben, haben Sie diesen Pool unwiderruflich mit einem Ger\u00e4t mit niedriger Leistung verschmutzt, und in der Regel gibt es keinen anderen Ausweg, als den Pool zu l\u00f6schen und von vorne zu beginnen. Selbst das Entfernen des vdev wird die falsche Konfiguration nicht retten. ashift<\/code>!<\/p>\n

Der Mechanismus des Schreibens<\/h3>\n

\n\"Grundlagen
\nWenn ein normales Dateisystem Daten neu schreiben muss, \u00e4ndert es jeden Block dort, wo er sich befindet.<\/i><\/p>\n

\"Grundlagen
\nDas Dateisystem mit Copy-on-Write schreibt eine neue Version des Blocks und entsperrt dann die alte Version.<\/i><\/p>\n

\"Grundlagen
\nIn abstrakter Form, wenn wir die tats\u00e4chliche physische Anordnung der Bl\u00f6cke ignorieren, vereinfacht sich unser \u201eDatenkomet\u201c zu einem \u201eDatenwurm\u201c, der sich von links nach rechts \u00fcber die verf\u00fcgbare Speicherkarte bewegt.<\/i><\/p>\n

\"Grundlagen
\nJetzt k\u00f6nnen wir uns ein gutes Bild davon machen, wie Snapshots mit Copy-on-Write funktionieren \u2013 jeder Block kann mehreren Snapshots angeh\u00f6ren und bleibt bestehen, bis alle zugeh\u00f6rigen Snapshots gel\u00f6scht werden.<\/i><\/p>\n

Der Mechanismus Copy-on-Write (CoW) ist das grundlegende Prinzip, das ZFS zu einem so erstaunlichen System macht. Das Hauptkonzept ist einfach \u2013 wenn Sie ein traditionelles Dateisystem bitten, eine Datei zu \u00e4ndern, wird es genau das tun, was Sie verlangen. Wenn Sie ein Copy-on-Write-Dateisystem dasselbe bitten, wird es sagen: \u201eIn Ordnung\u201c \u2013 aber es wird Sie anl\u00fcgen.<\/p>\n

Stattdessen schreibt das Copy-on-Write-Dateisystem eine neue Version des ge\u00e4nderten Blocks und aktualisiert die Metadaten der Datei, sodass die Verbindung zum alten Block getrennt und mit dem neuen Block, den Sie gerade geschrieben haben, verbunden wird.<\/p>\n

Das Trennen des alten Blocks und das Verkn\u00fcpfen des neuen Blocks erfolgt in einem einzigen Schritt, sodass es nicht unterbrochen werden kann \u2013 wenn Sie die Stromversorgung nach diesem Vorgang zur\u00fccksetzen, erhalten Sie die neue Version der Datei, und wenn Sie die Stromversorgung vorher zur\u00fccksetzen, haben Sie die alte Version. In jedem Fall treten im Dateisystem keine Konflikte auf.<\/p>\n

Copy-on-Write in ZFS geschieht nicht nur auf Dateisystemebene, sondern auch auf der Ebene des Festplattenspeichers. Das bedeutet, dass ZFS nicht anf\u00e4llig f\u00fcr das Schreibloch ist (Schreibloch im RAID<\/a><\/noindex>) \u2013 ein Ph\u00e4nomen, bei dem ein Stripe nur teilweise geschrieben werden konnte, bevor das System ausfiel, was zu einem besch\u00e4digten Array nach dem Neustart f\u00fchrt. Hier wird Stripe atomar geschrieben, vdev ist immer konsistent, und Bob ist dein Onkel.<\/a><\/noindex>.<\/p>\n

ZIL: ZFS Intent Log<\/h3>\n

\n\"Grundlagen
\nDas ZFS-System behandelt synchrone Schreibvorg\u00e4nge auf besondere Weise \u2013 es speichert sie vor\u00fcbergehend, aber sofort im ZIL, bevor es sie sp\u00e4ter zusammen mit asynchronen Schreibvorg\u00e4ngen dauerhaft speichert.<\/i><\/p>\n

\"Grundlagen
\nIn der Regel werden die im ZIL geschriebenen Daten nie wieder gelesen. Aber das ist nach einem Systemausfall m\u00f6glich.<\/i><\/p>\n

\"Grundlagen
\nSLOG, oder ein sekund\u00e4res LOG-Ger\u00e4t, ist einfach ein spezieller \u2013 idealerweise sehr schneller \u2013 vdev, wo ZIL getrennt vom Hauptspeicher aufbewahrt werden kann.<\/i><\/p>\n

\"Grundlagen
\nNach einem Ausfall werden alle schmutzigen Daten im ZIL wiederhergestellt \u2013 in diesem Fall befindet sich der ZIL auf dem SLOG, sodass sie genau von dort wiederhergestellt werden.<\/i><\/p>\n

Es gibt zwei Hauptkategorien von Schreiboperationen \u2013 synchrone (sync) und asynchrone (async). F\u00fcr die meisten Arbeitslasten sind \u00fcberwiegend mehr als 90 % der Schreiboperationen asynchron \u2013 das Dateisystem erm\u00f6glicht es, sie zu aggregieren und in Paketen auszugeben, was die Fragmentierung verringert und die Durchsatzrate erheblich steigert.<\/p>\n

Synchrone Schreibvorg\u00e4nge sind eine ganz andere Angelegenheit. Wenn eine Anwendung eine synchrone Speicherung anfordert, sagt sie dem Dateisystem: \u201eDu musst das in nichtfl\u00fcchtigem Speicher festhalten, jetzt gleich<\/i>, und bis dahin kann ich nichts anderes tun.\u201c Daher m\u00fcssen synchrone Schreibvorg\u00e4nge sofort auf der Festplatte festgeschrieben werden \u2013 und wenn das die Fragmentierung erh\u00f6ht oder die Durchsatzrate verringert, ist das eben so.<\/p>\n

ZFS behandelt synchrone Schreibvorg\u00e4nge anders als herk\u00f6mmliche Dateisysteme \u2013 anstatt sie sofort in den Standard-Speicher zu schreiben, speichert ZFS sie in einem speziellen Speicherbereich, der als ZFS Intent Log (ZIL) bezeichnet wird. Der Clou dabei ist, dass diese Eintr\u00e4ge auch<\/i> im Speicher aggregiert bleiben, zusammen mit den normalen asynchronen Schreibanfragen, um sp\u00e4ter als ganz normale TXG (Transaction Groups, Transaktionsgruppen) ins Speicherger\u00e4t geschrieben zu werden.<\/p>\n

Im normalen Betrieb wird ZIL geschrieben und danach nie wieder gelesen. Wenn nach einigen Momenten die Eintr\u00e4ge aus dem ZIL im Hauptspeicher in den \u00fcblichen TXG gespeichert werden, werden sie vom ZIL getrennt. Das einzige Mal, dass etwas aus dem ZIL gelesen wird, ist beim Import eines Pools.<\/p>\n

Wenn es zu einem ZFS-Ausfall kommt \u2013 sei es ein Betriebssystemabsturz oder ein Stromausfall \u2013 w\u00e4hrend sich Daten im ZIL befinden, werden diese Daten beim n\u00e4chsten Import des Pools (z.B. beim Neustart des Absturzsystems) gelesen. Alles, was sich im ZIL befindet, wird gelesen, in TXG-Gruppen zusammengef\u00fchrt, im Hauptspeicher festgeschrieben und dann w\u00e4hrend des Imports vom ZIL getrennt.<\/p>\n

Eine der Hilfsklassen vdev nennt sich LOG oder SLOG, das sekund\u00e4re Ger\u00e4t LOG. Es hat eine einzige Aufgabe \u2013 einen Pool mit einem separaten und, vorzugsweise, viel schnelleren Ger\u00e4t vdev mit sehr hoher Schreibbest\u00e4ndigkeit zum Speichern von ZIL bereitzustellen, anstelle von ZIL im Hauptspeicher vdev zu speichern. Das ZIL verh\u00e4lt sich unabh\u00e4ngig vom Speicherort gleich, aber wenn vdev mit LOG eine sehr hohe Schreibgeschwindigkeit hat, werden synchrone Schreibvorg\u00e4nge schneller ausgef\u00fchrt.<\/p>\n

Das Hinzuf\u00fcgen von vdev mit LOG zum Pool kann die kann<\/b> Leistung der asynchronen Schreibvorg\u00e4nge nicht verbessern \u2013 selbst wenn Sie alle Schreibvorg\u00e4nge in ZIL mithilfe von zfs set sync=always<\/code>erzwingen, werden sie dennoch in demselben Ma\u00dfe an den Hauptspeicher in TXG gebunden, wie ohne Journal. Die einzige direkte Leistungsverbesserung ist die Verz\u00f6gerung der synchronen Schreibvorg\u00e4nge (da eine h\u00f6here Journalgeschwindigkeit die Ausf\u00fchrung der Vorg\u00e4nge beschleunigt). sync<\/code>).<\/p>\n

In einer Umgebung, die bereits eine gro\u00dfe Anzahl synchroner Schreibvorg\u00e4nge ben\u00f6tigt, kann vdev LOG jedoch indirekt asynchrone Schreibvorg\u00e4nge und nicht zwischengespeicherte Lesevorg\u00e4nge beschleunigen. Das Auslagern von ZIL-Schreibvorg\u00e4ngen in ein separates vdev LOG bedeutet weniger Konkurrenz um IOPS im prim\u00e4ren Speicher, was die Leistung aller Lese- und Schreibvorg\u00e4nge in gewissem Ma\u00dfe steigert.<\/p>\n

Snapshots<\/h3>\n

\nDer Mechanismus der Schreibkopie ist auch eine notwendige Grundlage f\u00fcr atomare Momentaufnahmen von ZFS und inkrementelle asynchrone Replikation. In einem aktiven Dateisystem gibt es einen Baum von Zeigern, der alle Eintr\u00e4ge mit den aktuellen Daten markiert \u2013 wenn Sie einen Snapshot erstellen, machen Sie einfach eine Kopie dieses Zeigerbaums.<\/p>\n

Wenn ein Eintrag in einem aktiven Dateisystem \u00fcberschrieben wird, schreibt ZFS zuerst die neue Version des Blocks in nicht verwendeten Speicher. Anschlie\u00dfend trennt es die alte Version des Blocks vom aktuellen Dateisystem. Aber wenn irgendein Snapshot auf den alten Block verweist, bleibt er unver\u00e4ndert. Der alte Block wird faktisch nicht als freier Speicher wiederhergestellt, bis alle Snapshots, die auf diesen Block verweisen, gel\u00f6scht werden!<\/p>\n

Replikation<\/h3>\n

\n\"Grundlagen
\nMeine Steam-Bibliothek nahm im Jahr 2015 158 GiB in Anspruch und umfasste 126.927 Dateien. Das ist ziemlich nah an der optimalen Situation f\u00fcr rsync \u2013 die ZFS-Replikation \u00fcber das Netzwerk war \u201enur\u201c um 750 % schneller.<\/i><\/p>\n

\"Grundlagen
\nIm selben Netzwerk ist die Replikation einer 40-GiB gro\u00dfen Windows 7-VM-Image-Datei eine ganz andere Geschichte. ZFS-Replikation erfolgt 289-mal schneller als rsync \u2013 oder \"nur\" 161-mal schneller, wenn Sie genug wissen, um rsync mit dem Parameter --inplace aufzurufen.<\/i><\/p>\n

\"Grundlagen
\nWenn das Image der virtuellen Maschine skaliert, skaliert auch das rsync-Problem mit ihm. Eine Gr\u00f6\u00dfe von 1,9 TiB ist f\u00fcr ein modernes VM-Image nicht so gro\u00df \u2013 aber sie ist gro\u00df genug, damit die ZFS-Replikation 1148-mal schneller ist als rsync, selbst mit dem rsync-Argument --inplace.<\/i><\/p>\n

Sobald Sie verstehen, wie Snapshots funktionieren, wird es einfach sein, das Wesen der Replikation zu erfassen. Da ein Snapshot lediglich einen Baum von Zeigern auf die Datens\u00e4tze darstellt, folgt daraus, dass wenn wir einen zfs send<\/code> Snapshot erstellen, wir diesen Baum sowie alle damit verbundenen Datens\u00e4tze senden. Wenn wir dies \u00fcber zfs send<\/code> in zfs receive<\/code> auf das Zielobjekt \u00fcbertragen, schreibt es sowohl den tats\u00e4chlichen Blockinhalt als auch den Baum von Zeigern, die auf die Bl\u00f6cke verweisen, in den Ziel-Datensatz.<\/p>\n

Es wird noch interessanter beim zweiten zfs send<\/code>. Jetzt haben wir zwei Systeme, von denen jedes poolname\/datasetname@1<\/code>enth\u00e4lt, und Sie erstellen einen neuen Snapshot poolname\/datasetname@2.<\/code>Daher haben Sie im urspr\u00fcnglichen Pool datasetname@1<\/code> und datasetname@2<\/code>, w\u00e4hrend im Zielpool vorerst nur der erste Snapshot vorhanden ist. datasetname@1<\/code>.<\/p>\n

Da wir einen gemeinsamen Snapshot zwischen Quelle und Ziel haben, k\u00f6nnen wir einen datasetname@1<\/code>inkrementellen auf ihm durchf\u00fchren. Wenn wir zum System sagen<\/i> zfs send<\/code> zfs send -i poolname\/datasetname@1 poolname\/datasetname@2 , vergleicht es die beiden Zeigerb\u00e4ume. Alle Zeiger, die nur in<\/code>, verweisen offensichtlich auf neue Bl\u00f6cke \u2013 daher ben\u00f6tigen wir den Inhalt dieser Bl\u00f6cke. @2<\/code>Im entfernten System ist die Verarbeitung der inkrementellen<\/p>\n

ebenso einfach. Zuerst schreiben wir alle neuen Datens\u00e4tze, die im Stream enthalten sind, send<\/code> , und f\u00fcgen dann die Zeiger auf diese Bl\u00f6cke hinzu. Voil\u00e0, wir haben send<\/code>es im neuen System! @2<\/code> Asynchrone inkrementelle ZFS-Replikation ist eine enorme Verbesserung im Vergleich zu fr\u00fcheren Methoden, die nicht auf Snapshots basieren, wie rsync. In beiden F\u00e4llen werden nur die ge\u00e4nderten Daten \u00fcbertragen \u2013 aber rsync muss zuerst<\/p>\n

alle Daten von der Festplatte auf beiden Seiten lesen, um die Summe zu \u00fcberpr\u00fcfen und sie zu vergleichen. Im Gegensatz dazu liest die ZFS-Replikation nichts au\u00dfer den Zeigerb\u00e4umen \u2013 und allen Bl\u00f6cken, die im gemeinsamen Snapshot nicht vorhanden sind. lesen<\/i> Von der Festplatte werden alle Daten von beiden Seiten gelesen, um die Summe zu \u00fcberpr\u00fcfen und zu vergleichen. Im Gegensatz dazu liest die ZFS-Replikation nichts au\u00dfer den Zeigerb\u00e4umen \u2013 und beliebigen Bl\u00f6cken, die nicht im gemeinsamen Snapshot enthalten sind.<\/p>\n

Integrierte Kompression<\/h3>\n

\nDer Kopiermechanismus beim Schreiben vereinfacht auch das System der integrierten Kompression. In herk\u00f6mmlichen Dateisystemen ist die Kompression problematisch \u2013 sowohl die alte Version als auch die neue Version der ge\u00e4nderten Daten befinden sich im selben Raum.<\/p>\n

Wenn man einen Datenblock in der Mitte einer Datei betrachtet, der sein Leben als Megabyte an Nullen bei 0x00000000 beginnt und so weiter \u2013 l\u00e4sst er sich sehr leicht auf einen Sektor auf der Festplatte komprimieren. Aber was passiert, wenn wir dieses Megabyte an Nullen durch ein Megabyte unkomprimierbarer Daten wie JPEG oder pseudorandomem Rauschen ersetzen? \u00dcberraschenderweise ben\u00f6tigt dieses Megabyte an Daten nicht einen, sondern 256 Sektoren von 4 KiB, w\u00e4hrend an dieser Stelle auf der Festplatte nur ein Sektor reserviert ist.<\/p>\n

ZFS hat dieses Problem nicht, da ge\u00e4nderte Eintr\u00e4ge immer in ungenutzten Raum geschrieben werden \u2013 der urspr\u00fcngliche Block nimmt nur einen Sektor von 4 KiB ein, und der neue Eintrag ben\u00f6tigt 256, aber das ist kein Problem \u2013 der k\u00fcrzlich ge\u00e4nderte Abschnitt aus der \u201eMitte\u201c der Datei w\u00fcrde unabh\u00e4ngig von den \u00c4nderungen seiner Gr\u00f6\u00dfe in ungenutzten Raum geschrieben, daher ist dies f\u00fcr ZFS eine ganz normale Situation.<\/p>\n

Die integrierte Kompression von ZFS ist standardm\u00e4\u00dfig deaktiviert, und das System bietet ausw\u00e4hlbare Algorithmen an \u2013 derzeit darunter LZ4, gzip (1-9), LZJB und ZLE.<\/p>\n

Ist die Datei gro\u00df genug und ben\u00f6tigt mehrere Bl\u00f6cke, dann haben alle Aufzeichnungen mit dieser Datei die Gr\u00f6\u00dfe recordsize<\/code>\u00a0\u2013 einschlie\u00dflich der letzten Aufzeichnung, deren Hauptteil m\u00f6glicherweise unbenutzter Speicherplatz ist.<\/a><\/noindex>.<\/p>\n