Nicht alles was man im Internet findet sollte man auch nachmachen. Es gibt Leute die sich Filmen während sie sich ins Gemächt treten lassen - würde ich ebenfalls nie nachmachen
Gerade zum Thema ZFS gibt es so einige gruselige und zweifelhafte Anleitungen. Ohne zu wissen was man da wirklich treibt sollte man grundsätzlich die Finger von _jedem_ 'how-to' lassen, erst recht wenn man vor hat dem entstandenen Monstrum seine Daten anzuvertrauen...
ZFS hat exzellente manpages; dort findet man schon die wichtigsten Grundlagen und eine Übersicht wie und warum ZFS so funktioniert wie es das tut und was im vergleich zu anderen FS beachtet werden sollte.
Alles weitere kann man sich über viel suchen und Dokumentation und/oder Quellcode bzw dessen Kommentare zusammensuchen - oder komprimiert, unterhaltsam und mit vielen Erfahrungen/Beispielen/Empfehlungen in den beiden genannten Büchern (die gemessen am Informationsgehalt spottbillig sind!)
Wenn es nur ein READ-Cache war? Warum sollte der Pool dann degraded sein? Von ZFS erwarte ich eigentlich soviel Mitdenken, dass er nicht den ganzen Pool gegen die Wand fährt, nur weil der L2ARC ausfällt.
Es fehlt ein provider, also ist der pool degraded. Da alle Daten aber noch zugänglich sind (auf den HDDs) arbeitet aber noch weiter, ansonsten wäre er FAULTED. Wenn auf dem USB-Stick auch noch ein SLOG gewesen wäre, hätte ZFS den pool deaktiviert (FAULTED), weil ein Teil der Daten (alle dirty writes die noch im log waren) fehlen - der pool müsste dann zuerst manuell wiederhergestellt werden indem er auf die letzte erfolgreiche "known good" transaktion zurückgesetzt wird.
Ich habe dir nur geraten den pool zu exportieren und ohne mounts wieder zu importieren, um zu verhindern dass auf den pool wieder "normal" zugegriffen wird und damit die von dir beschriebenen Symptome (lockups/timeouts) ausgelöst werden, bis du das Problem gefunden und behoben hast.
Bei mir wachen die Festplatten etwa 3 mal pro Tag auf. (Heimserver)
Wie hoch sind die power_cycle_counts der platten?
ZFS schreibt (sofern nicht geändert) mindestens alle 30sek eine transaktionsgruppe bzw sobald sie voll ist; dazu kommen metadaten (atime auch bei daten aus dem cache!) und natürlich periodische snapshots oder evtl laufende scrubs. Selbst auf einem leeren pool summiert sich das so weit, dass Platten mit extrem kurzen standby-timeouts immer sofort wieder aufgeweckt werden.
Da ZFS stark "burstig" schreibt, da transaktionen gesamelt und dann zusammen in einem langen zugriff linear geschrieben werden, kann das bei Platten mit extrem kurzen timeouts (WD green...
) exakt so interferieren, dass die platte unmittelbar vor dem nächsten flush in standby geht, nur um sofort wieder für die nächste TXgroup aufgeweckt zu werden. Der Zugriff hat dann extrem hohe Latenzen, was ZFS u.U. zusätzlich veranlasst stark zu throtteln (um die vermeintlich ausgelastete Platte zu schonen), was die Performance endgültig in die Knie reißt.
Man *könnte* ZFS soweit zurechtstutzen dass es damit zurechtkommt - der Aufwand und die Nachteile lohnen sich aber in keinster Weise. I.d.r. wiegen die kosten für häufige HDD-Defekte durch den extrem hohen Verschleiß beim anlaufen/ausschalten die Stromkosten beim Dauerlauf wieder auf - zumal es heutzutage etliche Serverplattenserien gibt, die für "lauwarmen" Speicher mit niedrigen I/O Anforderungen optimiert sind und sehr geringen Leistungsbedarf haben (2-3W im "freien Flug" ohne I/O)
Wenn man einen Storageserver Zuhause betreibt, macht es ohnehin Sinn dieses Datengrab auch für alles zu nutzen; dann ergibt sich automatisch ein ständiger bedarf an I/O; dafür spart man dann an den anderen Systemen. Mein Desktop hat Z.B. nur noch 1x 256MB NVMe und 2x 256MB SSD - alles was potentiell viel Speicherbedarf hat landet auf mounts am Storageserver. Testsysteme und ein NUC im Wohnzimmer laufen komplett ohne eigene Platten - die booten von NFS oder zvols am server. Man spart sich damit je nach Anzahl der Systeme im Haus massenhaft verteilte HDDs/SSDs die nie voll genutzt werden - dafür kann man eine Handvoll HDDs locker durchlaufen lassen...
SMART Werte (4x HDD, 2x SSD):
40579
load_cycle_count weit >3000 - q.e.d.
Dazu kommen extrem hohe command_timeout werte und viele power-off-retract-counts (=saft weg währrend die platte sich ausschaltet, also cache leert und in parkstellung geht).
hoher raw-wert für seek_error_rate ist bei seagate normal, die haben noch immer nicht gelernt normal zu zählen
Ein gut gemeinter Rat, da hier auch mal 6 Seagate ST4000VN in Betrieb waren: Migriere die Daten auf andere Platten und trenne dich ASAP von den Seagates. Ausfallrate betrug hier 100% in den ersten 2 Jahren, von den RMA-Platten sind 4 innerhalb eines Jahres wieder ausgefallen
Mit anderen Seagate Serien in den letzten ~5 Jahren sah es oft nicht besser aus.
Mittlerweile gibt es hier für spinning rust nur noch HGST oder ggf noch WD.
3 Pools:
- mypool: 4x HDD Festplatten im raid-z1 (ja, kenne die Diskussionen um raid-z1) und ashift: 12. Blocksize habe ich nicht geändert.
- ctpool: SSD ohne Verschlüsselung, ashift: 9
- sofo: SSD, ashift: 12
Zum Verständniss: ashift = alignment in 2^ashift bytes
SSDs melden sich leider immer noch mit blocksize von 512 bytes (danke an Redmont; deren spielzeug-OS hatte nämlich anno dazumal probleme mit größeren blöcken, daher dieser bescheuerte hack
) - korrekt wäre _mindestens_ 4k bzw für halbwegs aktuelle SSDs 8k. Je nach dem was auf den SSDs liegt können auch größere Blockgrößen (bis 1MB) Sinn machen um den overhead beim schreiben/lesen zu verringern und etwas mehr Performance zu bekommen (der Platzberarf-overhead durch padding steigt aber natürlich!).
Für SSD-pools also ashift=13, für HDDs die nicht nativ mit 512b arbeiten ashift=12
Raidz-1 ist OK, performance und overhead ist nicht gerade optimal, aber es gibt schlimmeres. Ich persönlich gehe bei 4 platten aber eher auf 2x2 mirror (+1 spare je nach system)
Bisher unterstützt ZFS keine Verschlüsselung, daher liegt ZFS bei mir auf verschlüsselten Volumes.
ZoL hat doch bereits seit einiger zeit native Verschlüsselung für datasets? In FreeBSD-CURRENT ist es AFAIK noch als experimentell markiert bzw deaktiviert.
Grundsätzlich sollte ZFS immer direkt auf die Platte; ohne Zwischenschicht oder Abstraktion (auch kein hw-raid!). Verschlüsselung ist gerade an einem Storageserver der ständig läuft IMHO auf Dateiebene besser aufgehoben - sobald der Server läuft sind die daten ohnehin entschlüsselt zugänglich. Die Verschlüsselung unterhalb von ZFS schützt also nur im unwahrscheinlichen Fall dass dir jemand alle Platten ausbaut und klaut...
Verschlüsselung auf Dateiebene ermöglicht alle normalen Backupstrategien ohne dass die Daten danach unverschlüsselt rumliegen und ist auch sonst wesentlich flexibler - ich habe den hype oder angeblich "dringenden Bedarf" an nativer Verschlüsselung in ZFS daher nie wirklich verstanden. Der einzig "halbwegs" sinnvolle Anwendungsfall wäre ggf mobile Geräte (Laptop); aber selbst hier ist IMHO Dateibasierte Verschlüsselung die bessere und flexiblere Wahl.
Nur meine Meinung dazu - hoffentlich wird der Thread jetzt nicht für Glaubenskriege missbraucht
