In diesem Frühjahr haben wir bereits einige einführende Themen besprochen, z. B. wie Sie die Geschwindigkeit Ihrer Laufwerke überprüfen und was RAID ist . In der zweiten haben wir sogar versprochen, die Leistung verschiedener Multi-Disk-Topologien in ZFS weiter zu untersuchen. Dies ist das Dateisystem der nächsten Generation, das überall implementiert wird: von Apple bis Ubuntu .

Nun, heute ist der beste Tag, um ZFS kennenzulernen, neugierige Leser. Beachten Sie jedoch, dass es nach einer konservativen Einschätzung des OpenZFS-Entwicklers Matt Arens "sehr kompliziert" ist.

Aber bevor wir zu den Zahlen kommen - und ich verspreche es -, müssen Sie für alle Varianten der vosmidiskovoy ZFS-Konfiguration darüber sprechen, wie ZFS Daten auf der Festplatte speichert.

Zpool, vdev und Gerät

Dieses vollständige Pooldiagramm enthält drei Hilfs-VDEVs, einen für jede Klasse und vier für RAIDz2. Normalerweise

gibt es keinen Grund, einen Pool unangemessener VDEV- Typen und -Größen zu erstellen. Wenn Sie möchten, hindert Sie nichts daran

, das ZFS-Dateisystem wirklich zu verstehen müssen Sie sich die tatsächliche Struktur genau ansehen. Erstens kombiniert ZFS traditionelle Ebenen der Datenträgerverwaltung und das Dateisystem. Zweitens wird beim Schreiben ein Transaktionskopiermechanismus verwendet. Diese Merkmale bedeuten, dass sich das System strukturell stark von normalen Dateisystemen und RAID-Arrays unterscheidet. Die ersten grundlegenden Bausteine, die zu verstehen sind: ein Speicherpool (zpool), ein virtuelles Gerät (vdev) und ein reales Gerät (Gerät).

zpool

Der zpool-Speicherpool ist die oberste ZFS-Struktur. Jeder Pool enthält ein oder mehrere virtuelle Geräte. Jedes von ihnen enthält wiederum ein oder mehrere reale Geräte (Geräte). Virtuelle Pools sind autonome Blöcke. Ein physischer Computer kann zwei oder mehr separate Pools enthalten, aber jeder ist völlig unabhängig von den anderen. Pools können keine virtuellen Geräte gemeinsam nutzen.

Die Redundanz von ZFS erfolgt auf der Ebene der virtuellen Geräte, jedoch nicht auf der Ebene der Pools. Auf Poolebene gibt es absolut keine Redundanz. Wenn ein vdev-Laufwerk oder ein spezielles vdev verloren geht, geht der gesamte Pool verloren.

Moderne Speicherpools können den Verlust eines Cache- oder virtuellen Geräteprotokolls überleben - obwohl sie eine kleine Menge schmutziger Daten verlieren können, wenn sie das vdev-Protokoll während eines Stromausfalls oder eines Systemabsturzes verlieren.

Es gibt ein weit verbreitetes Missverständnis, dass „Datenbänder“ (Streifen) von ZFS über den gesamten Pool aufgezeichnet werden. Das ist nicht wahr. Zpool ist überhaupt kein lustiges RAID0, sondern ein lustiges JBOD mit einem komplexen veränderbaren Verteilungsmechanismus.

Die Datensätze werden größtenteils entsprechend dem verfügbaren Speicherplatz auf die verfügbaren virtuellen Geräte verteilt, sodass sie theoretisch alle gleichzeitig gefüllt werden. In späteren Versionen von ZFS wird die aktuelle Verwendung (Auslastung) von vdev berücksichtigt. Wenn ein virtuelles Gerät erheblich stärker als das andere geladen ist (z. B. aufgrund der Leselast), wird es trotz des höchsten freien Speicherplatzkoeffizienten vorübergehend zum Schreiben übersprungen.

Ein in moderne ZFS-Datensatzverteilungsmethoden integrierter Mechanismus zur Erkennung von Recycling kann die Latenz verringern und den Durchsatz in Zeiten ungewöhnlich hoher Last erhöhen - dies ist jedoch kein Freibriefunwillkürliches Mischen langsamer Festplatten und schneller SSDs in einem Pool. Solch ein ungleicher Pool arbeitet immer noch mit der Geschwindigkeit des langsamsten Geräts, das heißt, als ob es vollständig aus solchen Geräten zusammengesetzt wäre.

vdev

Jeder Speicherpool besteht aus einem oder mehreren virtuellen Geräten (virtuelles Gerät, vdev). Jedes vdev enthält wiederum ein oder mehrere reale Geräte. Die meisten virtuellen Geräte werden zum einfachen Speichern von Daten verwendet, es gibt jedoch mehrere vdev-Hilfsklassen, darunter CACHE, LOG und SPECIAL. Jeder dieser vdev-Typen kann eine von fünf Topologien haben: Einzelgerät, RAIDz1, RAIDz2, RAIDz3 oder Spiegel.

RAIDz1, RAIDz2 und RAIDz3 sind spezielle Variationen der sogenannten RAID-Doppelparität (Diagonale). 1, 2 und 3 beziehen sich darauf, wie viele Paritätsblöcke für jedes Datenband zugewiesen sind. Anstelle separater Festplatten für die Parität verteilen virtuelle RAIDz-Geräte diese Parität gleichmäßig auf die Festplatten. Ein RAIDz-Array kann so viele Festplatten verlieren, wie es Paritätsblöcke enthält. Wenn er einen anderen verliert, wird er scheitern und den Speicherpool mitnehmen.

In gespiegelten virtuellen Geräten (Spiegel vdev) wird jeder Block auf jedem Gerät in vdev gespeichert. Obwohl es sich um die gängigsten Spiegel mit zwei Breiten handelt, kann sich eine beliebige Anzahl von Geräten im Spiegel befinden. In großen Installationen werden häufig dreifache Geräte verwendet, um die Leseleistung und die Fehlertoleranz zu erhöhen. Der vdev-Spiegel kann jeden Fehler überstehen, während mindestens ein Gerät in vdev weiterhin funktioniert.

Einzelne vdevs sind von Natur aus gefährlich. Ein solches virtuelles Gerät überlebt einen einzelnen Fehler nicht - und wenn es als Speicher oder als spezielles vdev verwendet wird, führt sein Ausfall zur Zerstörung des gesamten Pools. Sei hier sehr, sehr vorsichtig.

Virtuelle CACHE-, LOG- und SPECIAL-Appliances können mit einer der oben genannten Topologien erstellt werden. Beachten Sie jedoch, dass der Verlust einer virtuellen SPECIAL-Appliance den Verlust eines Pools bedeutet. Daher wird eine übermäßige Topologie dringend empfohlen.

Gerät

Dies ist wahrscheinlich der am einfachsten zu verstehende Begriff in ZFS - es handelt sich buchstäblich um ein Block-Direktzugriffsgerät. Denken Sie daran, dass virtuelle Geräte aus einzelnen Geräten bestehen und der Pool aus virtuellen Geräten besteht.

Festplatten - magnetisch oder Festkörper - sind die am häufigsten verwendeten Blockgeräte, die als vdev-Bausteine verwendet werden. Es ist jedoch jedes Gerät mit einem Handle in / dev geeignet, sodass Sie ganze Hardware-RAID-Arrays als separate Geräte verwenden können.

Eine einfache Rohdatei ist eines der wichtigsten alternativen Blockgeräte, aus denen vdev erstellt werden kann. Testen Sie Pools aus Dateien mit geringer Dichte - Eine sehr bequeme Möglichkeit, Poolbefehle zu überprüfen und festzustellen, wie viel Speicherplatz im Pool oder auf dem virtuellen Gerät dieser Topologie verfügbar ist.

Sie können in wenigen Sekunden einen Testpool aus Dateien mit geringer Dichte erstellen. Vergessen Sie jedoch nicht, den gesamten Pool und seine Komponenten später zu löschen.

Angenommen, Sie möchten einen Server auf acht Festplatten installieren und planen, 10-TB-Festplatten (~ 9300 GiB) zu verwenden. Sie sind sich jedoch nicht sicher, welche Die Topologie entspricht am besten Ihren Anforderungen. Im obigen Beispiel erstellen wir in Sekundenschnelle einen Testpool aus Dateien mit geringer Dichte - und jetzt wissen wir, dass RAIDz2 vdev von acht 10-TB-Laufwerken eine nützliche Kapazität von 50 TiB bietet.

Eine weitere spezielle Geräteklasse ist SPARE (Ersatz). Hot-Swap-fähige Geräte gehören im Gegensatz zu herkömmlichen Geräten zum gesamten Pool und nicht nur zu einem virtuellen Gerät. Wenn ein vdev im Pool ausfällt und das Ersatzgerät mit dem Pool verbunden und verfügbar ist, wird es automatisch dem betroffenen vdev beitreten.

Nach dem Herstellen einer Verbindung zum betroffenen vdev empfängt das Ersatzgerät Kopien oder die Rekonstruktion von Daten, die sich auf dem fehlenden Gerät befinden sollten. In herkömmlichem RAID wird dies als Neuerstellung bezeichnet, während es in ZFS als "Resilvering" bezeichnet wird.

Es ist wichtig zu beachten, dass Ersatzgeräte ausgefallene Geräte nicht dauerhaft ersetzen. Dies ist nur ein vorübergehender Ersatz, um die Zeit zu verkürzen, in der eine vdev-Verschlechterung beobachtet wird. Nachdem der Administrator das ausgefallene vdev-Gerät ersetzt hat, wird die Redundanz auf diesem permanenten Gerät wiederhergestellt, und SPARE trennt sich von vdev und kehrt als Ersatz für den gesamten Pool zurück.

Datensätze, Blöcke und Sektoren

Die nächsten Bausteine, die Sie auf unserer Reise durch ZFS verstehen müssen, sind nicht so sehr die Hardware, sondern die Organisation und Speicherung der Daten. Wir überspringen hier mehrere Ebenen - wie z. B. Metaslab -, um die Details nicht zu häufen und gleichzeitig das Verständnis der Gesamtstruktur zu bewahren.

Datensatz

Wenn wir zum ersten Mal ein Dataset erstellen, wird der gesamte verfügbare Poolbereich angezeigt. Dann legen wir das Kontingent fest - und ändern den Einhängepunkt. Magie!

Zvol ist größtenteils nur ein Datensatz ohne Dateisystemschicht, den wir hier durch ein völlig normales ext4-

Dateisystem ersetzen. Der ZFS-Datensatz entspricht in etwa einem standardmäßig bereitgestellten Dateisystem. Wie ein normales Dateisystem scheint es auf den ersten Blick „nur ein weiterer Ordner“ zu sein. Wie bei herkömmlichen gemounteten Dateisystemen verfügt auch jedes ZFS-Dataset über eigene grundlegende Eigenschaften.

Zunächst kann einem Datensatz ein Kontingent zugewiesen werden. Wenn installiertzfs set quota=100G poolname/datasetname, können Sie nicht/poolname/datasetnamemehr als 100 GiBin den bereitgestellten Ordner schreiben.

Beachten Sie das Vorhandensein - und Fehlen - von Schrägstrichen am Anfang jeder Zeile? Jeder Datensatz hat seinen eigenen Platz sowohl in der ZFS-Hierarchie als auch in der System-Mount-Hierarchie. In der ZFS-Hierarchie gibt es keinen führenden Schrägstrich. Sie beginnen mit dem Namen des Pools und dann mit dem Pfad von einem Datensatz zum nächsten. Zum Beispiel pool/parent/childfür ein Dataset, das childunter dem übergeordneten Dataset parentin einem Pool mit einem Creative-Namen benannt ist pool.

Standardmäßig wird die Mount - Punkt des Datensatz auf seinen Namen in der ZFS - Hierarchie entspricht, mit einem Schrägstrich am Anfang - der Pool mit dem Namen wird poolmontiert , wie /poolder Datensatz wird parentin montiert /pool/parent, und der Kind - Datensatz wird montiert childin /pool/parent/child. Der System-Mount-Punkt für das Dataset kann jedoch geändert werden.

Wenn wir angebenzfs set mountpoint=/lol pool/parent/child, dann wird der Datensatz pool/parent/childim System als gemountet /lol.

Zusätzlich zu Datensätzen sollten wir Volumes (zvols) erwähnen. Ein Volume ähnelt ungefähr einem Datensatz, außer dass es tatsächlich kein Dateisystem hat - es ist nur ein Blockgerät. Sie können beispielsweise zvoleinen Namen erstellen mypool/myzvol, ihn dann mit dem ext4-Dateisystem formatieren und dann dieses Dateisystem bereitstellen - jetzt haben Sie das ext4-Dateisystem, aber mit Unterstützung für alle ZFS-Sicherheitsfunktionen! Dies mag auf einem Computer albern erscheinen, ist jedoch als Backend beim Exportieren eines iSCSI-Geräts viel sinnvoller.

Blöcke

Eine Datei wird durch einen oder mehrere Blöcke dargestellt. Jeder Block wird auf einem virtuellen Gerät gespeichert. Die Blockgröße entspricht normalerweise dem Parameter recordsize , kann jedoch auf 2 ^ ashift reduziert werden, wenn sie Metadaten oder eine kleine Datei enthält.

Wir scherzen wirklich, wirklich nicht über den großen Leistungsschaden, wenn Sie zu wenig Ashift installieren.

Im ZFS-Pool werden alle Daten, einschließlich Metadaten, in Blöcken gespeichert. Die maximale Blockgröße für jeden Datensatz wird in der Eigenschaftrecordsize(Datensatzgröße) definiert. Die Größe des Datensatzes kann variieren, dies ändert jedoch nicht die Größe oder Position von Blöcken, die bereits in das Dataset geschrieben wurden. Sie gelten nur für neue Blöcke, während sie geschrieben werden.

Sofern nicht anders angegeben, beträgt die aktuelle Aufzeichnungsgröße standardmäßig 128 KB. Dies ist eine Art schwieriger Kompromiss, bei dem die Leistung nicht ideal, aber in den meisten Fällen nicht schrecklich ist. Recordsizekann auf einen beliebigen Wert von 4K bis 1M eingestellt werden (mit zusätzlichen Einstellungen können recordsizeSie noch mehr einstellen, dies ist jedoch selten eine gute Idee).

Jeder Block bezieht sich auf die Daten nur einer Datei. Sie können nicht zwei verschiedene Dateien in einem Block zusammenfassen. Jede Datei besteht je nach Größe aus einem oder mehreren Blöcken. Wenn die Dateigröße kleiner als die Datensatzgröße ist, wird sie in einem kleineren Block gespeichert. Beispielsweise belegt ein Block mit einer 2-KiB-Datei nur einen 4-KiB-Sektor auf der Festplatte.

Wenn die Datei groß genug ist und mehrere Blöcke erfordert, haben alle Datensätze mit dieser Datei eine Größerecordsize - einschließlich des letzten Eintrags, von dem sich der größte Teil als ungenutzter Speicherplatz herausstellen kann .

Zvol-Volumes haben keine Eigenschaft, recordsize sondern eine entsprechende Eigenschaft volblocksize.

Sektoren

Der letzte, grundlegendste Baustein ist der Sektor. Dies ist die kleinste physische Einheit, die in die Basiseinheit geschrieben oder von dieser gelesen werden kann. Mehrere Jahrzehnte lang verwendeten die meisten Festplatten 512-Byte-Sektoren. In letzter Zeit sind die meisten Laufwerke für 4-KiB-Sektoren und in einigen - insbesondere SSDs - 8-KiB-Sektoren oder sogar mehr konfiguriert.

ZFS verfügt über eine Eigenschaft, mit der Sie die Sektorgröße manuell festlegen können. Dies ist eine Eigenschaft ashift. Es ist etwas verwirrend, dass Ashift eine Zweierpotenz ist. Zum Beispiel ashift=9bedeutet dies eine Sektorgröße von 2 ^ 9 oder 512 Bytes.

ZFS fragt das Betriebssystem nach detaillierten Informationen zu jedem Blockgerät, wenn es dem neuen vdev hinzugefügt wird, und stellt die Verschiebung basierend auf diesen Informationen theoretisch automatisch richtig ein. Leider lügen viele Festplatten über ihre Sektorgröße, um die Kompatibilität mit Windows XP aufrechtzuerhalten (das Festplatten mit anderen Sektorgrößen nicht verstehen konnte).

Dies bedeutet, dass dem ZFS-Administrator dringend empfohlen wird, die tatsächliche Sektorgröße seiner Geräte zu kennen und manuell zu installierenashift. Wenn eine zu kleine Verschiebung eingestellt ist, nimmt die Anzahl der Lese- / Schreibvorgänge astronomisch zu. Das Schreiben von 512-Byte-Sektoren in den realen 4-KiB-Sektor bedeutet also, den ersten „Sektor“ zu schreiben, dann den 4-KiB-Sektor zu lesen, ihn durch den zweiten 512-Byte-Sektor zu ändern, ihn in den neuen 4-KiB-Sektor zurückzuschreiben und so weiter für jeden Eintrag.

In der realen Welt schlägt eine solche Strafe Samsung EVO- ashift=13SSDs , für die sie handeln muss , aber diese SSDs liegen in Bezug auf ihre Sektorgröße und sind daher standardmäßig festgelegt ashift=9. Wenn ein erfahrener Systemadministrator diese Einstellung nicht ändert, ist diese SSD langsamer als eine normale magnetische Festplatte.

Zum Vergleich für eine zu große GrößeashiftEs gibt praktisch keine Strafe. Es gibt keine wirkliche Abnahme der Produktivität, und die Zunahme des nicht genutzten Speicherplatzes ist unendlich gering (oder gleich Null bei aktivierter Komprimierung). Wir empfehlen daher dringend, auch Laufwerke zu installieren, die wirklich 512-Byte-Sektoren verwenden, ashift=12oder sogar ashift=13sicher in die Zukunft zu schauen.

Die Eigenschaft wird ashiftfür jedes virtuelle vdev-Gerät festgelegt und nicht für den Pool , wie viele fälschlicherweise denken - und ändert sich nach der Installation nicht. Wenn Sie ashiftbeim Hinzufügen eines neuen vdev zum Pool versehentlich heruntergefahren wurden , haben Sie diesen Pool unwiderruflich mit einem Gerät mit geringer Leistung kontaminiert. In der Regel gibt es keine andere Möglichkeit, als den Pool zu zerstören und von vorne zu beginnen. Selbst das Entfernen von vdev rettet Sie nicht vor einem fehlerhaften Setupashift!

— ,

, , « » « »,

, — , ,

Copy on Write (CoW) ist die grundlegende Grundlage dafür, was ZFS so großartig macht. Das Grundkonzept ist einfach: Wenn Sie das herkömmliche Dateisystem bitten, die Datei zu ändern, wird es genau das tun, was Sie angefordert haben. Wenn Sie das Dateisystem mit dem Kopieren während der Aufnahme auffordern, dasselbe zu tun, wird "gut" angezeigt - aber es wird Sie anlügen.

Stattdessen schreibt das Copy-Write-Dateisystem die neue Version des geänderten Blocks und aktualisiert dann die Dateimetadaten, um die Verbindung zum alten Block zu trennen und den neuen Block zuzuordnen, den Sie gerade geschrieben haben.

Das Trennen des alten Geräts und das Verbinden des neuen Geräts erfolgt in einem Arbeitsgang, sodass es nicht unterbrochen werden kann. Wenn Sie danach die Stromversorgung zurücksetzen, haben Sie eine neue Version der Datei. Wenn Sie die Stromversorgung früher zurücksetzen, haben Sie die alte Version. In jedem Fall liegt kein Konflikt im Dateisystem vor.

Das Kopieren beim Schreiben in ZFS erfolgt nicht nur auf Dateisystemebene, sondern auch auf Datenträgerverwaltungsebene. Dies bedeutet, dass ZFS keinem Leerzeichen im Datensatz unterliegt (einem Loch im RAID ) - ein Phänomen, bei dem der Strip vor dem Systemabsturz nur teilweise aufzeichnen konnte und das Array nach einem Neustart beschädigt wurde. Hier ist der Streifen atomar, vdev ist immer konsistent und Bob ist dein Onkel .

ZIL: ZFS-Absichtsprotokoll

ZFS — , ZIL,

, ZIL, .

SLOG, LOG-, — — , , — vdev, ZIL

ZIL — ZIL SLOG,

Es gibt zwei Hauptkategorien von Schreibvorgängen - synchron (synchron) und asynchron (asynchron). Bei den meisten Workloads ist die überwiegende Mehrheit der Schreibvorgänge asynchron. Mit dem Dateisystem können Sie sie aggregieren und stapelweise bereitstellen, wodurch die Fragmentierung verringert und der Durchsatz erheblich erhöht wird.

Synchrone Aufnahmen sind eine ganz andere Sache. Wenn eine Anwendung ein synchrones Schreiben anfordert, teilt sie dem Dateisystem mit: "Sie müssen dies jetzt in den nichtflüchtigen Speicher übertragen , und bis dahin kann ich nichts mehr tun." Daher sollten synchrone Aufzeichnungen sofort auf die Festplatte übertragen werden - und wenn dies die Fragmentierung erhöht oder die Bandbreite verringert, ist dies auch der Fall.

ZFS verarbeitet synchrone Datensätze anders als normale Dateisysteme. Anstatt sie sofort in den regulären Speicher hochzuladen, zeichnet ZFS sie in einem speziellen Speicherbereich auf, der als ZFS-Absichtsprotokoll - ZFS-Absichtsprotokoll oder ZIL - bezeichnet wird. Der Trick besteht darin, dass diese Datensätze auch im Speicher verbleiben und zusammen mit regulären asynchronen Schreibanforderungen aggregiert werden, um später als ganz normale TXGs (Transaktionsgruppen, Transaktionsgruppen) gespeichert zu werden.

Im Normalbetrieb wird ZIL aufgezeichnet und nie wieder gelesen. Wenn nach einigen Augenblicken Aufzeichnungen von ZIL im Hauptspeicher in normalem TXG aus dem RAM fixiert werden, werden sie von ZIL getrennt. Das einzige, was aus ZIL gelesen wird, ist das Importieren des Pools.

Wenn ZFS abstürzt - Betriebssystemabstürze oder Stromausfälle -, wenn Daten in ZIL vorhanden sind, werden diese Daten beim nächsten Poolimport gelesen (z. B. beim Neustart des Notfallsystems). Alles, was sich in der ZIL befindet, wird gelesen, in TXG-Gruppen zusammengefasst, in den Hauptspeicher übernommen und dann während des Importvorgangs von der ZIL getrennt.

Eine der vdev-Hilfsklassen heißt LOG oder SLOG, das sekundäre LOG-Gerät. Er hat eine Aufgabe - dem Pool ein separates und vorzugsweise viel schnelleres vdev-Gerät mit sehr hohem Schreibwiderstand zum Speichern von ZIL zur Verfügung zu stellen, anstatt ZIL im vdev-Hauptspeicher zu speichern. ZIL selbst verhält sich unabhängig vom Speicherort gleich. Wenn jedoch vdev mit LOG eine sehr hohe Schreibleistung aufweist, sind synchrone Schreibvorgänge schneller.

Das Hinzufügen von vdev mit LOG zum Pool kann die asynchrone Schreibleistung nicht verbessern. Selbst wenn Sie alle Schreibvorgänge in ZIL erzwingen zfs set sync=always, werden sie auf dieselbe Weise und im gleichen Tempo wie ohne Protokoll an das Hauptrepository in TXG gebunden. Die einzige direkte Leistungsverbesserung ist die Verzögerung bei der synchronen Aufzeichnung (da eine höhere Protokollgeschwindigkeit den Betrieb beschleunigt sync).

In einer Umgebung, in der bereits eine große Anzahl synchroner Schreibvorgänge erforderlich ist, kann vdev LOG jedoch indirekt asynchrone Schreibvorgänge und nicht zwischengespeicherte Lesevorgänge beschleunigen. Das Hochladen von ZIL-Datensätzen in ein separates vdev-LOG bedeutet weniger Konkurrenz für IOPS im Primärspeicher, was die Leistung aller Lese- und Schreibvorgänge in gewissem Maße verbessert.

Schnappschüsse

Der Schreibkopiermechanismus ist auch eine wesentliche Grundlage für atomare ZFS-Snapshots und inkrementelle asynchrone Replikation. Das aktive Dateisystem verfügt über einen Zeigerbaum, der alle Datensätze mit aktuellen Daten markiert. Wenn Sie einen Snapshot erstellen, erstellen Sie einfach eine Kopie dieses Zeigerbaums.

Wenn ein Datensatz im aktiven Dateisystem überschrieben wird, schreibt ZFS zuerst die neue Version des Blocks in den nicht verwendeten Speicherplatz. Anschließend wird die alte Version des Blocks vom aktuellen Dateisystem getrennt. Wenn sich ein Schnappschuss jedoch auf den alten Block bezieht, bleibt er unverändert. Der alte Block wird erst dann als freier Speicherplatz wiederhergestellt, wenn alle Snapshots, die mit diesem Block verknüpft sind, zerstört wurden!

Reproduzieren

Steam 2015 158 126 927 . rsync — ZFS « » 750% .

40- Windows 7 — . ZFS 289 , rsync — «» 161 , , rsync --inplace.

, rsync . 1,9 — , ZFS 1148 , rsync, rsync --inplace

Sobald Sie die Funktionsweise von Snapshots verstanden haben, können Sie die Essenz der Replikation leicht erfassen. Da ein Snapshot nur ein Baum von Zeigern auf Datensätze ist, zfs sendsenden wir diesen Baum und alle damit verbundenen Datensätze , wenn wir einen Snapshot erstellen. Wenn wir dies passieren zfs sendin zfs receiveauf das Zielobjekt, schreibt sie sowohl den eigentlichen Inhalt des Blocks und den Baum von Zeigern, die die Blöcke auf den Zieldatensatz verweisen.

Im zweiten wird alles noch interessanter zfs send. Jetzt haben wir zwei Systeme, von denen jedes enthält poolname/datasetname@1, und Sie schießen einen neuen Schnappschuss poolname/datasetname@2. Daher haben Sie im Quellpool datasetname@1und datasetname@2und im Zielpool bisher nur den ersten Snapshot datasetname@1.

Da haben wir einen gemeinsamen Schnappschuss zwischen der Quelle und dem Zieldatasetname@1können wir inkrementell tun zfs send. Wenn wir dem System mitteilen zfs send -i poolname/datasetname@1 poolname/datasetname@2, werden zwei Zeigerbäume verglichen. Alle Zeiger, die nur in vorhanden @2sind, beziehen sich offensichtlich auf neue Blöcke - daher benötigen wir den Inhalt dieser Blöcke.

Auf einem Remote-System ist die inkrementelle Verarbeitung sendgenauso einfach. Zuerst zeichnen wir alle neuen Einträge auf, die im Stream enthalten sind send, und fügen dann Zeiger zu diesen Blöcken hinzu. Voila, in unserem @2neuen System!

Die asynchrone inkrementelle ZFS-Replikation ist eine enorme Verbesserung gegenüber früheren Nicht-Snapshot-Methoden wie rsync. In beiden Fällen werden nur geänderte Daten übertragen - rsync muss jedoch zuerst gelesen werdenvon der Festplatte alle Daten auf beiden Seiten, um die Menge zu überprüfen und zu vergleichen. Im Gegensatz dazu liest die ZFS-Replikation nur Zeigerbäume - und alle Blöcke, die im allgemeinen Snapshot nicht dargestellt sind.

Inline-Komprimierung

Der Copy-on-Write-Mechanismus vereinfacht auch das integrierte Komprimierungssystem. In einem herkömmlichen Dateisystem ist die Komprimierung problematisch - sowohl die alte als auch die neue Version der geänderten Daten befinden sich im selben Bereich.

Wenn Sie ein Datenelement in der Mitte einer Datei betrachten, das sein Leben als Megabyte von Nullen ab 0x00000000 usw. beginnt, ist es sehr einfach, es auf einen Sektor auf der Festplatte zu komprimieren. Aber was passiert, wenn wir dieses Megabyte Nullen durch ein Megabyte inkompressibler Daten wie JPEG oder pseudozufälliges Rauschen ersetzen? Plötzlich benötigt dieses Megabyte an Daten nicht einen, sondern 256 Sektoren mit 4 KB, und an dieser Stelle auf der Festplatte ist nur ein Sektor reserviert.

ZFS hat kein solches Problem, da geänderte Datensätze immer in nicht verwendeten Speicherplatz geschrieben werden - der ursprüngliche Block belegt nur einen 4-KiB-Sektor, und ein neuer Datensatz benötigt 256, dies ist jedoch kein Problem - ein kürzlich geändertes Fragment aus der Mitte der Datei würde in nicht verwendeten Speicherplatz geschrieben Unabhängig davon, ob sich die Größe geändert hat oder nicht, ist dies für ZFS eine normale Situation.

Die integrierte ZFS-Komprimierung ist standardmäßig deaktiviert und das System bietet Plug-In-Algorithmen - darunter LZ4, gzip (1-9), LZJB und ZLE.

LZ4 ist ein Streaming-Algorithmus, der für die meisten Anwendungsfälle extrem schnelle Komprimierung und Dekomprimierung sowie Leistungssteigerungen bietet - selbst auf relativ langsamen CPUs.
GZIP — , Unix-. 1-9, CPU 9. ( ) , c CPU — , .
LZJB — ZFS. , LZ4 .
ZLE - Zero Level Coding, Zero Level Coding. Es berührt überhaupt keine normalen Daten, komprimiert jedoch große Folgen von Nullen. Nützlich für vollständig inkompressible Datensätze (z. B. JPEG, MP4 oder andere bereits komprimierte Formate), da inkompressible Daten ignoriert werden, jedoch nicht verwendeter Speicherplatz in den resultierenden Datensätzen komprimiert wird.

Wir empfehlen die LZ4-Komprimierung für fast alle Anwendungsfälle. Die Leistungseinbuße für inkompressible Daten zu begegnen ist sehr klein, und die Leistungsverstärkung für typische Daten ist signifikant. Das Kopieren eines Images einer virtuellen Maschine für eine Neuinstallation des Windows-Betriebssystems (frisch installiertes Betriebssystem, noch keine Daten darin) wurde in diesem Test 2015compression=lz4 27% schneller als mit bestanden .compression=none

ARC - adaptiver Ersatzcache

ZFS ist das einzige uns bekannte moderne Dateisystem, das einen eigenen Lese-Caching-Mechanismus verwendet und nicht auf den Seiten-Cache des Betriebssystems angewiesen ist, um Kopien kürzlich gelesener Blöcke im RAM zu speichern.

Obwohl der eigene Cache nicht ohne Probleme ist, kann ZFS nicht so schnell wie der Kernel auf neue Speicherzuweisungsanforderungen reagieren, sodass ein neuer malloc()Speicherzuweisungsaufruf möglicherweise fehlschlägt, wenn RAM benötigt wird, das derzeit von ARC belegt ist. Aber es gibt gute Gründe, zumindest vorerst einen eigenen Cache zu verwenden.

Alle bekannten modernen Betriebssysteme, einschließlich MacOS, Windows, Linux und BSD, verwenden den LRU-Algorithmus (Least Recent Used), um den Seitencache zu implementieren. Dies ist ein primitiver Algorithmus, der den zwischengespeicherten Block nach jedem Lesen in die Warteschlange stellt und die Blöcke in der Warteschlange nach Bedarf verschiebt, um neue Cache-Fehler (Blöcke, die von der Festplatte und nicht vom Cache gelesen werden sollten) hinzuzufügen.

Normalerweise funktioniert der Algorithmus einwandfrei, aber auf Systemen mit großen Arbeitsdatensätzen führt LRU leicht zu Thrashing - Verdrängung häufig benötigter Blöcke, um Platz für Blöcke zu schaffen, die nie wieder aus dem Cache gelesen werden.

BOGEN - ein viel weniger naiver Algorithmus, der als "gewichteter" Cache betrachtet werden kann. Nach jedem Lesen des zwischengespeicherten Blocks wird es etwas „schwerer“ und es wird schwieriger, sich zu verdrängen - und selbst nach dem Verdrängen wird der Block für einen bestimmten Zeitraum verfolgt . Ein Block, der herausgedrückt wurde, dann aber in den Cache zurückgelesen werden muss, wird ebenfalls "schwerer".

Das Endergebnis all dessen ist ein Cache mit einer viel größeren Trefferquote - dem Verhältnis zwischen Treffern im Cache (aus dem Cache gelesen) und Fehlern (von der Festplatte gelesen). Dies ist eine äußerst wichtige Statistik. Der Cache trifft nicht nur selbst Service-Größenordnungen schneller, Cache-Misses können auch schneller bedient werden. Je mehr Cache-Hits, desto weniger gleichzeitige Festplattenanforderungen und desto geringer die Verzögerung für die verbleibenden Misses, die bedient werden sollen Fahrt.

Fazit

Nachdem wir uns mit der grundlegenden Semantik von ZFS befasst haben - wie das Kopieren beim Schreiben funktioniert - sowie mit den Beziehungen zwischen Speicherpools, virtuellen Geräten, Blöcken, Sektoren und Dateien, können wir die tatsächliche Leistung mit realen Zahlen diskutieren.

Im nächsten Teil werden wir die tatsächliche Leistung von Pools mit gespiegeltem vdev und RAIDz im Vergleich untereinander sowie im Vergleich zu herkömmlichen Linux-Kernel-RAID-Topologien untersuchen, die wir zuvor untersucht haben .

Zuerst wollten wir nur die Grundlagen betrachten - die ZFS - Topologien selbst - aber nach dieser werden wir bereit sein , über Fortgeschrittene ZFS - Tuning und Tuning zu sprechen, einschließlich der Verwendung von Hilfs vdev Typen wie L2ARC, SLOG und Sonder Allocation.

ZFS-Grundlagen: Speicher und Leistung