zfs

Welches Problem es löst

Bei einem Pool, auf dem laufende virtuelle Maschinen und Container liegen, bedeutet eine Änderung der RAIDZ-Redundanz oder das Entfernen einer Platte heute ein Wartungsfenster: Gäste verschieben, Pool exportieren, neu aufbauen, alles zurückholen. Die RAIDZ-Erweiterung in OpenZFS 2.3 brachte nur das Online-Verbreitern. Ziel dieser Arbeit ist es, die Geometrie eines laufenden Pools an Ort und Stelle zu ändern, nur mit dem freien Platz des Pools selbst und unter Erhalt von Snapshots und Klonen.

Wichtigste Funktionen

• zpool reparity erhöht oder senkt die RAIDZ-Parität an Ort und Stelle (raidz1 ↔ raidz2 ↔ raidz3); mit --online bleiben die Datasets eingehängt, mit --async, --status und --cancel läuft der Vorgang im Hintergrund.
• Eine Layout-Epochen-Tabelle pro vdev hinter einem einzigen neuen Feature-Flag (Arbeitsname com.openzfs:raidz_parity_epochs): Jeder Block wird in der Geometrie gelesen und rekonstruiert, in der er geschrieben wurde.
• Fail-closed-Commit: Die neue Parität gilt erst, wenn eine Zählung keine Blöcke mit der alten mehr findet; sonst wird der Durchlauf fortgesetzt, auch nach einem Absturz.
• Offline-Werkzeuge in zhack: eine Platte aus einem RAIDZ-vdev entfernen (N → N−1), Umbau mit Snapshots und Klonen, vorhandene Daten mit neuen Prüfsummen versehen und neu komprimieren; die letzten beiden sind experimentell.
• ZTS-Funktionstests und Manpages für die neuen Befehle; ein RFC und eine gestapelte Reihe von Branches, vorbereitet für das Upstream-Review.

So funktioniert es

Jedes RAIDZ-vdev der obersten Ebene erhält eine kleine, nur erweiterbare Tabelle mit {start_txg, width, parity}-Einträgen, in derselben Form wie die vorhandenen Einträge der RAIDZ-Erweiterung. Die Geometrie eines Blocks richtet sich nach seiner Geburts-txg, sodass alte und neue Blöcke nebeneinander bestehen. Ein begrenzter, nach einem Absturz fortsetzbarer Durchlauf schreibt die vorhandenen Blöcke per gewöhnlichem Copy-on-Write neu. Die RAIDZ-Zeilenkodierung, das Format der Blockzeiger und ashift ändern sich nicht.

zpool reparity [--online | --async | --status | --cancel] [--target N] pool

Voraussetzungen

• Ein Pool mit RAIDZ-vdevs. Das Feature-Flag ist inkompatibel und wird mit dem ersten Umbau aktiv.
• Wird wie OpenZFS aus dem Quellcode gebaut. Die Branches ozfs-pr/1-parity-epochs-recon, ozfs-pr/2-reparity-command und ozfs-pr/3-reshape-toolkit basieren auf master, feat/raidz-* auf zfs-2.4.4.
• Für das Entfernen einer Platte und die Offline-Werkzeuge in zhack muss der Pool exportiert sein.