Wie ZFS mit dem Online-Austausch in einem RAID-Z umgeht (theoretisch)

Dies ist eine etwas theoretische Frage zu ZFS und RAID-Z. Ich werde aus Gründen der Übersichtlichkeit ein Single-Parity-Array mit drei Festplatten als Beispiel verwenden, aber das Problem kann auf eine beliebige Anzahl von Festplatten und eine beliebige Parität ausgedehnt werden.

Angenommen, wir haben die Datenträger A, B und C im Pool und sie sind sauber.

Angenommen, wir fügen jetzt Datenträger D physisch hinzu, um Datenträger C zu ersetzen, und Datenträger C funktioniert weiterhin ordnungsgemäß und wird nur aus vorbeugenden Gründen ersetzt. Einige Administratoren ziehen möglicherweise nur C und installieren D, was etwas besser organisiert ist, da Geräte die IDs nicht ändern müssen. Dadurch wird das Array jedoch vorübergehend beeinträchtigt. Nehmen wir in diesem Beispiel an, wir installieren D, ohne C. Solaris-Dokumente zu entfernen oder zu entfernen Wir können eine Festplatte ersetzen, ohne sie zuerst zu entfernen, indem wir einen Befehl wie den folgenden verwenden:

zpool replace pool C D

Dies sollte ein Resilvering auf D verursachen. Nehmen wir an, dass das Resilvering entlang eines "Cursors" "nach unten" verläuft. (Ich kenne die tatsächliche Terminologie, die in der internen Implementierung verwendet wird, nicht.)

Angenommen, auf halbem Weg durch das Resilvering fällt Festplatte A aus. Theoretisch sollte dies wiederherstellbar sein, da oberhalb des Cursors B und D eine ausreichende Parität und unterhalb des Cursors B und C eine ausreichende Parität enthalten ist. Ob dies tatsächlich wiederherstellbar ist oder nicht, hängt jedoch von internen Entwurfsentscheidungen in ZFS ab, die mir nicht bekannt sind (und die im Handbuch in bestimmten Begriffen nicht angegeben sind).

Wenn ZFS weiterhin Schreibvorgänge an C unterhalb des Cursors sendet, ist alles in Ordnung. Wenn ZFS C jedoch intern so behandelt, als wäre es weg, indem es D nur aus der Parität zwischen A und B entfernt und nur A und B unter den Cursor schreibt, stoßen wir an.

Einige Experimente könnten diese Frage beantworten, aber ich hatte gehofft, dass vielleicht jemand hier bereits weiß, wie ZFS mit dieser Situation umgeht. Vielen Dank im Voraus für jeden Einblick!

Das Testen mit einem dateibasierten Pool (Version 28 unter FreeBSD 8.3 mit dateibasierten MD-Geräten) legt nahe, dass dies funktionieren sollte. Ich konnte eine der verbleibenden Festplatten offline schalten, während der Resilver ausgeführt wurde. Im Idealfall müssten Tests mit echten Festplatten durchgeführt und tatsächlich eine gezogen werden, um 100% sicher zu sein, aber ZFS war vollkommen glücklich, mich die Festplatte offline schalten zu lassen.

Vor dem Auslagern von md0 war der Pool noch vollständig ONLINE, daher scheint es mir, dass ZFS nur die ersetzte Festplatte auf die neue Festplatte spiegelt, aber das gesamte Los weiterhin als während des Prozesses verfügbar behandelt.

    NAME                     STATE     READ WRITE CKSUM
    test                     DEGRADED     0     0     0
      raidz1-0               DEGRADED     0     0     0
        8480467682579886773  OFFLINE      0     0     0  was /dev/md0
        md1                  ONLINE       0     0     0
        replacing-2          ONLINE       0     0     0
          md2                ONLINE       0     0     0
          md3                ONLINE       0     0     0  (resilvering)

Datenträger C wird im RAIDZ weiterhin genau so verwendet, wie er war, bis er aus dem VDev entfernt wurde. Wie Matt betont, ersetzt ZFS eine Festplatte, indem die Ersatzfestplatte zum Spiegel des Ersatzdatenträgers wird und die Ersatzfestplatte ausdauert. Der RAIDZ VDev wird niemals beeinträchtigt und niemals ausgemustert (bis A ausfällt, was völlig unabhängig vom Austauschvorgang ist).

Ich bin mir nicht sicher, ob das wichtig ist.

In den meisten Fällen sollten Sie RAIDZ nicht im Vergleich zu Spiegeln verwenden. Wenn Sie dies tun, sollten Sie dies mit einem Ersatzgerät tun.

Das Resilvering schlägt fehl, wenn eine der Festplatten, von denen gelesen wird, ausfällt oder nicht verfügbar ist. Entspricht einem nicht behebbaren Lesefehler . Datenträger C wäre zu diesem Zeitpunkt verschwunden ...