ZFS + GELI führt zu Prüfsummenfehlern

jmt

jmt

Well-Known Member
Hallo,

ich brauche mal Eure Hilfe. Mein Homeserver hat ein Upgrade erhalten. Ein neues Board mit N100 und eine 20TB Platte zur Datenhaltung sollen einen Stromsparenden Server ergeben. Dazu kommen 32GB Ram und eine 1TB Nvme. Das System lief zunächst mit Proxmox ohne Probleme. Nachdem ich aber gelesen habe, dass ZFS mit eigener Verschlüsselung merkwürdige Fehler erzeugen soll, insbesondere bei der intensiven Verwendung von Snapshots und zfs send/recv, will ich wieder GELI zur Verschlüsselung einsetzen. Da ich zur Sicherung auf ein Backupsystem zfs-autobackup verwende, finde ich die Problematik extrm unschön. Also zurück zu FreeBSD (ist mir eh lieber) und seiner GELI Verschlüsselung. Darauf dann ein ZFS und man muss sich auch keinen Kopf mehr darüber machen, ob das Filesystem nun verschlüsselt ist oder nicht. Soweit alles normal. FreeBSD ließ sich problemlos installieren. Einige Daten, die nicht auf dem Backupserver gesichert werden, wurden mit restic auf der Nvme zwischengelagert. Ich habe also auf der Datenplatte eine Partition eingerichtet, GELI initialisiert und dann einen Zpool erstellt. Wenn ich nun das Backup zurückspiele, dann erhalte ich Datenfehler. Restic meldet errno 97 und der Zpool meldet Prüfsummenfehler. Ich habe das ganze Prozedere wiederholt, d.h. Pool, GELI und Partition gelöscht, Anfang und Ende mit Nullen beschrieben, gebootet und alles von vorne begonnen. Beim Restore gibt es wieder errno 97 und Prüfsummenfehler. Aber nicht bei den gleichen Dateien. Ich habe die Platte mit smartctl ausgelesen und es sind keine Fehler verzeichnet. Auch FreeBSD meldet mir "nur" Prüfsummenfehler. Kein DMA oder sonstiges Problem. Dann habe ich den Zpool ohne GELI und mit ZFS eigener Verschlüsselung erstellt. Jetzt lief der Restore mit Verify ohne Fehler durch.

Die Zpools wurden immer mit gleichen Einstellungen erstellt. compression=lz4, atime=off, exec=off, setuid=off, devices=off. Der Pool ohne GELI hat halt noch encryption=on und keyformat=passphrase. GELI wurde mit -s 4096 -l 256 erstellt. Der Zpool dann mit ashift=12, da ich sicher sein wollte, dass er auch 4096 Byte Blöcke verwendet.

Jetz frage ich mich, was ich falsch mache. Früher hat das immer funktioniert. Und soweit mir bekannt verwendet der Installer von FreeBSD auch noch GELI zur Verschlüsselung der Root-Platte. Ideen sind wie immer wilkommen...

PS: Ich wiederhole gerade den Restore mit stress, so dass ich CPU und deren Temperatur auslaste. Mal schauen, ob das etwas ändert. Mit GELI war die Last nämlich höher als mit der ZFS eigenen Verschlüsselung. (Muss ja nicht heißen, aber wer weiß...)
 
Hast du dich eventuell irgendwo beim Devicenamen vertan? Also z.b. ZFS nicht auf das Geli Device gemacht oder ähnliches? Oder altes Gelidevice mit gleichen Pfad nicht zuerst geschlossen? Eventuell anstatt NULLEN auch mal wipefs -a auf die ZFS Platte lassen. Zum testen könntest du auch mal Geli mit Checksums einrichten, mal sehen ob da schon Fehler kommen. Ich hatte mal etwas ähnliches als ich (unter Linux) ein cryptsetup Device nicht geschlossen hatte, und zufällig eine Anwendung dann über das noch vorhandene Cryptsetupdevice zugreifen wollte, was aber nicht mehr zum Datenträger gepasst hat.

Nochmal um sicher zu gehen: Du hast von restic ein Dateibackup eingespielt, keinen weggesicherten zfs send stream oder? Denn der ZFS Send Stream wäre ja auch verschlüsselt wenn er von einem verschlüsselten Dataset kommt.

Was die Zuverlässigkeit von ZFS Encryption angeht: Das ist seit Mitte 2019 vom ZFS Team als production ready in openzfs. Wenn du denkst, die Leute haben so wenig Plan von dem was sie tun, dass da 5 Jahre danach noch häufige und grobe Fehler sind: Lass die Finger von ZFS!

Was diese Bugreports angeht, die da in einem anderen Thread hier verlinkt wurden: Jeder mit nem Github Account kann im ZFS Projekt einen Bug erstellen und auch Labels wie "Defect" hinzufügen. Das bedeutet also erstmal wenig. Auch sieht man, das fast alle diese Bugs von ubuntuusern kommen - die ja openzfs nicht plain ausliefern, sondern noch etwas eigenes dazudoktorn. Zugegeben nutzt aber sicher auch ein großer Teil der Linux-ZFS User Ubuntu, weil die es eben offiziell supporten. Aber die Fixes für z.b. den kritischen Bug Ende November, den openzfs wenige Tage darauf gefixed hatte (inkl Backports zu allen alten Versionen) hat Canonical noch in keinem ihrer 3 derzeit supporteten LTS Versionen gefixt.
 
jmt schrieb:
GELI wurde mit -s 4096 -l 256 erstellt. Der Zpool dann mit ashift=12, da ich sicher sein wollte, dass er auch 4096 Byte Blöcke verwendet.
Zum Vergrößern anklicken....
Ja, korrekt. Was ist das für ein exaktes Modell der Platte? 512, 512e oder 4kn und wie ist sie formatiert? smartctl -xund dann bei physical/logical zeigt den Ist-Zustand. Das führt jetzt höchstwahrscheinlich nicht zu deinem Fehler, du verschenkst aber Performance und Platz wenn eine 4kn auf 512 formatiert ausgeliefert wurde. Das nur am Rande, da du eh grade am Fummeln bist...nachher, wenn der pool gefüllt ist und man stellt es fest, ärgert man sich. ;)

jmt schrieb:
Restic meldet errno 97
Zum Vergrößern anklicken....
Ich kenne restic nicht, weiß daher nicht, was da geschrieben werden soll. Ganz stumpf würde ich zunächst mal einige testfiles ganz regulär auf ein testdataset schreiben...da reichts, wenn man irgendne .iso mit 1-2GB aus dem Netz draufzieht und dabei den pool beobachtet. Wenn das ok ist, liegts eher an restic irgendwo/irgendwie und was das zurückschreiben will.

Vorstellen könnte ich mir auch, dass falls aus restic irgendne Art ZFS-stream rauspurzeln soll und dieser ist/war verschlüsselt, er zunächst geöffnet werden muss, damit man ihn in ein offenes dataset schreiben kann.

jmt schrieb:
Dann habe ich den Zpool ohne GELI und mit ZFS eigener Verschlüsselung erstellt. Jetzt lief der Restore mit Verify ohne Fehler durch.
Zum Vergrößern anklicken....
Bestätigt das wahrscheinlich. Also dann wirds einen Schritt mehr brauchen. Also zpool auf geli. Darauf ein datasetA mit ZFS-Verschlüsselung anlegen, dieses aufmachen. Restic dort reinschreiben lassen. Zweites datasetB ohne native Verschlüsselung anlegen, zfs send von weiterhin offenem A nach B dudeln lassen und nicht -w / --raw dabei benutzen.
-w, --raw
For encrypted datasets, send data exactly as it exists on disk. This allows backups to be taken even if encryption keys are not currently loaded. The backup may then be received on an untrusted machine since that machine will not have the encryption keys to read the protected data or alter it without being detected. Upon being received, the dataset will have the same encryption keys as it did on the send side, although the keylocation property will be defaulted to prompt if not otherwise provided. For unencrypted datasets, this flag will be equivalent to -Lec. Note that if you do not use this flag for sending encrypted datasets, data will be sent unencrypted and may be re-encrypted with a different encryption key on the receiving system, which will disable the ability to do a raw send to that system for incrementals.
Zum Vergrößern anklicken....

zfs-send.8 — OpenZFS documentation

openzfs.github.io openzfs.github.io
 
Zunächst einmal vielen Dank für Eure Antworten!

Vorweg möchte ich sagen, dass ich den OpenZFS Leuten schon vertraue. Und das Zfs Encryption seit 2019 als production ready gilt war mir sogar nicht bekann. Ich bin durch den Thread über den letzten OpenZFS Bug auf "die Probleme" mit der Verschlüsselung aufmerksam gewroden. Und dort beschriebenen Fehler sind alle unspezifisch. Und ich weiß auch nicht, wie oft die native ZFS Verschlüsselung wirklich eingesetzt wird. Wie schon geschrieben, der ZFS Installer benutzt immer noch GELI auf ZFS. Aber Dank der Hinweise von @medV2 werde ich wohl doch wieder die native ZFS Verschlüsselung benutzen. Sie hat den massiven Vorteil, dass ich ein Backup machen kann ohne die Pools zu entsperren. Und mein "Backup-Konzept" sieht vor, dass mein Backup-Rechner beim Start ein Backup macht und sich auch wieder ausschaltet, wenn sich kein Benutzer angemeldet hat.

Nichtsdestotrotz sollte ZFS auf GELI ja funktionieren. Die Platte ist eine TOSHIBA MG10ACA20TE mit 512 bytes logical, 4096 bytes physical. In restic sind die Dateien des Pools gespeichert und kein ZFS Stream. Es funktioniert also wie ein tar Archiv.

Der gestern gestartete Stresstest mit restic restore auf nativer ZFS Verschlüsselung + zusätzlicher Last mittels stress. ist ohne Fehler durchgelaufen. Dabei habe ich das restic restore mit --verify durchgeführt. So werden die Daten nach dem restore auch noch einmal mit dem Backup verglichen. Das System wurde dabei bis zu 90 °C heiß und hat sich gedrosselt. Wäre es also ein Problem von zuviel Hitze, so müsste das aufgefallen sein. Der Restore dauert etwas über 1,5 Stunden.

Ich werde es noch einmal mit GELI und ZFS versuchen. Einen Teil der Daten habe ich auch als tar-Archiv. Die werde ich dann mal einspielen.
 
Gesagt, getan.

Ich bekomme gerade komisch Fehler, wenn ich auf das GELI+ZFS zugreife. Es schmiert mir tmux mit signal 11 ab und dann bekomme ich einen Bus Error im tar???

Ach ja, der Prozessor ist ein N100. Kann das ein Problem darstellen?
 
jmt schrieb:
Und ich weiß auch nicht, wie oft die native ZFS Verschlüsselung wirklich eingesetzt wird.
Zum Vergrößern anklicken....
Nicht repräsentativ, aber ich hab das problemlos am Laufen seit es verfügbar ist, aber trotzdem weiterhin geli drunter. Ein wenig merkt man schon den overhead, aber ich bekomme dafür das Beste beider Welten und bleibe flexibel. Ich habe auch immer den Gedanken im Hinterkopf, dass wenn eine Platte die Hufe hebt, ich sie einfach entsorgen kann ohne irgendwas datenmäßig zu leaken.

jmt schrieb:
TOSHIBA MG10ACA20TE mit 512 bytes logical, 4096 bytes physical
Zum Vergrößern anklicken....
Das ist das 512e-Modell und somit korrekt formatiert. Übrigens auch eine CMR, somit auch kein etwaiges SMR-Problem. :)
Da steht auch eine max. Betriebstemperatur von 55°C für die Platte innen am hot spot. Überschreitet sie das oder kratzt daran, 'trippt' sie und ZFS wirft Fehler. SMART sollte dann was anzeigen und das in die dmesg spucken, wenn aktiv.

jmt schrieb:
Das System wurde dabei bis zu 90 °C heiß
Zum Vergrößern anklicken....
Was genau? Die CPU? Kommt mir zu heiß vor, wenn schon gedrosselt wird, sowieso. Aber ich bin fast ausschließlich bei AMD heimisch.
Wenn das Ding passiv gekühlt ist, staut sich das und brät alle Komponenten ringsum...gefährlich wirds dann nochmal beim RAM. Überhitzte CPU und RAM sind ein Garant für Murks.
www.intel.de

Informationen zur Temperatur für Intel® Prozessoren

Erläutert temperaturbedingte Probleme mit Intel Prozessoren.
www.intel.de www.intel.de
sagt jetzt 100-110°, aber kann das gut sein?

jmt schrieb:
der Prozessor ist ein N100. Kann das ein Problem darstellen?
Zum Vergrößern anklicken....
Nein, es sollte nur x64 sein. ;)

Kannst du das irgendwie aktiv runterkühlen und nochmal versuchen?
 
Ich werde gleich mal provisorisch einen Kühler anbringen. An zu viel Hitze dachte ich auch schon. Aber wieso klappt es dann ohne GELI? Da wird das System genauso heiß und mittels des Tools stress habe ich es sogar dauerhaft um 90 Grad betrieben. Gemeint ist hier übrigens die CPU. Die Festplatte hatte laut SMART maximal 48 Grad bei erlaubten 60.
 
jmt schrieb:
Aber wieso klappt es dann ohne GELI?
Zum Vergrößern anklicken....
Kann Zufall sein oder geli drückt die CPU um exakt 1°C zuviel hoch...dunno.
Das mit der Drossel ist auch eher ein Schutz, damit sich die CPU nicht kaputtgrillt und keine langfristige Dauerlösung.
Beim Auto die Gänge immer bis zum Begrenzer treten kost' irgendwann auch teuer Geld. :D

Edit: denke auch mal an die Sommermonate, ob dann mit 5-10° mehr auf den jeweiligen Komponenten nicht ein Elephant's Foot aus Lötzinn erscheint.
 
Nicht in den Begrenzer zu fahren bringt eher Performance als das etwas kaputt geht (Wenn man davon absieht, dass Elektronik bei höherer Temperatur schneller altert). Wie auch immer, ich habe einen großen Lüfter über dem Board befestigt. Damit bekommt das gesamte Board Luft ab. Das hat zwa die Temperatur gesenkt, aber den Fehler nicht beseitigt. Dann habe ich das Ram von 3200 auf 2400 gesenkt. Das hatte aber auch keine Auswirkungen. Ich bin gerade echt ratlos. Unter Linux (Proxmox) habe ich allerhand Schabernack mit dem System getrieben ohne das es Probleme gab. Mit der nativen ZFS Verschlüsselung kann ich nebenbei das System stressen und die Temperatur an den Anschlag jagen (das war noch ohne Lüfter!), ohne dass etwas passiert. Mit GELI habe ich die seltsamsten Fehler...

Mit GELI's Verify bekomme ich keine Meldungen während des Restores, aber die Fehler bleiben. Ich habe jetzt auch mal das RAM-Modul getauscht und ein 16GB Modul eingesetzt mit ARC auf 4GB beschränkt /Dachte erst, es wäre ein 8er...). Die Fehler bleiben. Das neue RAM-Modul ist definitiv in Ordnung. Ich bin mit meinem Latein am Ende...
 
Wenn das Verify von GELI (also -a) keine Fehler wirft, ZFS in dem Zusammenhang aber schon ist das echt misteriös..

Reines Rumgerate:

Probier mal ein Restore von etwas anderem (großes Tar z.b. falls du keins hast, lad den Linuxkernel als tar und mach ein extract auf die ZFS Partition)

Probier mal nen anderen Encryption Mode - also aes-cbc oder gar NULL. Vieleicht nutzt GELI AES-NI anders als openZFS - keine Ahnung nur wildes gerate.
 
Ich habe immer noch die Vermutung, dass mit restic oder dem backup was nicht stimmt, wenn die Temperatur nun 100% passt und das auch:

Funktioniert ein unverschlüsseltes dataset auf geli und darauf einmal ein fetch https://download.freebsd.org/releases/ISO-IMAGES/14.0/FreeBSD-14.0-RELEASE-amd64-dvd1.iso mit anschließendem scrub fehlerfrei?
 
Ich bin immer verwirrter. Das restic restore hatte Fehler in einer Datei. Der Pool meldet nun folgendes:
Code: 
root@mcp:~ # zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          ada0p1.eli  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        /tank/backup/proxmox/rpool/ENC/data/subvol-1038-disk-1/var/lib/docker/volumes/nextcloud-main/nextcloud.tar
Wie kann das denn sein?
 
Ah, da hat geli Fehler gemeldet. Aber sollte dann nicht auch ein Fehler bei READ WRITE oder CKSUM sein? Ich entpacke hier gerade tar-Archive. Ein paar hatte ich erstellt bevor ich restiv verwendet hatte. Meine SSD ist etwas zu klein für das Backup und da dort vieles Jails liegen bietet sich Deduplizierung an.
 
ZFS hat wohl das File (oder Teile davon) gar nicht erst geschrieben oder? Alles wirklich interessant (auch wenn ich den Fehler ungern selbst hätte :D )
 
Du bist jetzt genauso wie ich stolzer Besitzer einer Intel N100 CPU vom sympathischen, qualitätsbewussten Weltmarktführer. Die CPU ist an sich gut, leider ist Intel trotz höchster Ansprüche an Validierung in allen Alder Lake und Raptor Lake E-Cores die PCID-Implementierung sagen wir mal kaputt gegangen. Genauer gesagt korrumpiert der INVLPG Opcode den TLB.

Phoronix hat da nenn Artikel zu: https://www.phoronix.com/news/Intel-Disable-PCID-ADL-RP
Und hier ist der Linux-Commit: https://git.kernel.org/pub/scm/linu.../?id=ae8373a5add4ea39f032563cf12a02946d1e3546

Das dort versprochene Microcode-Update gibt es bis heute nicht. Die letzte Version aus https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files listet für Alder Lake und co. zwar unspezifische "Update for functional issues" und gefühlt wurden die Probleme geringer, aber triggern konnte ich sie immer noch.

An sich hat FreeBSD dafür einen Work Around aber im Fall des N100 greift der anscheinend nicht zu 100%. Hier gibt es eine Diskussion darüber: https://lists.freebsd.org/archives/freebsd-current/2023-August/004116.html

Lange rede, kurzer Sinn. Mache es wie Linux. Schreibe vm.pmap.pcid_enabled=0 in deine /boot/loader.conf, reboote und die Chancen sind gut, dass die Maschine dann läuft wie sie soll. Da die CPU laut Intel nicht gegen Meltdown anfällig ist, sollte (Konjunktiv!) der Verzicht auf PCID erstmal keine sicherheitsrelevanten Nebenwirkungen haben.
 
Zuletzt bearbeitet:
Damals beim Gleitkommaberechnungsfehler des Pentium 1 gabs wenigstens ein Umtauschrecht (was tatsächlich immer noch gilt).
 
Das heißt ja, das die auch noch Pentiums auf Lager haben.
Ich hab hier irgendwo sogar noch ein 90er Jahre Pentium rumliegen. Allerdings ich glaube, das ist das schon ein Pentium mit MMX. Möglicherweise der, mit den bunten, tanzenden Reinraumingieneuren.
Der, der das Internet schneller macht. :-)
 
Erst einmal ein riesig großes Dankeschön and alle und besonders an @Yamagi ! Da wäre ich nie drauf gekommen. Und das ganze ist schon von März 2023. Nun ja, den N100 gibt es ja auch schon ein bißchen...

Ich habe den Eintrag in der loader.conf gesetzt und das System wieder in seinen ursprünglichen Zustand versetzt. Nur die Lüfter sind geblieben.:)
Ich habe wieder GELI mittels der Parameter -l 256 und -s 4096 erstellt. Darauf dann einen Zpool erzeugt und spiele mittels restic das Backup ein. Bisher läuft alles super. Allerdings ist die Maschine irgendwie schneller geworden. Das Backup scheint nur noch 1 statt 1,5 Stunden zu brauchen und die CPU ist mit dem Setting auch kühler. Kann das sein? Ich habe ganz bestimmt nichts dagegen...
 
Es ist einfach nur jämmerlich. Klar, CPUs sind irre komplex, da passieren halt Fehler. Aber hier geht es um den TLB, Quell endloser CPU Errata Listen und siliziumgewordene Bestätigung der alten Weisheit, das Cache Invalidation eines der härtesten Probleme der Informatik überhaupt ist. AMD kann seit Barcelona vor fast 20 Jahren ein ganz besonders trauriges Lied davon singen. Wenn ich CPU-Hersteller bin, schaue ich bei der Validierung da doch ganz besonders genau hin und übersehe nicht einen Bug, der sich vergleichsweise trivial triggern lässt. Und vor allem schleppe ich das Problem nicht in Neuaufgüsse der CPU weiter, eben Raptor Lake und und hier die N-Serie. Da hat es doch bestimmt eh neue Belichtungsmasken gebraucht, wo man es hätte reparieren können, wenn es kein reines Microcode-Problme sein sollte. Oder zumindest hätte man sich keinen Zacken aus der Krone gebrochen, das Feature im Microcode der Neuaufgüsse von Anfang an zu deaktivieren.
 
jmt schrieb:
Allerdings ist die Maschine irgendwie schneller geworden. Das Backup scheint nur noch 1 statt 1,5 Stunden zu brauchen und die CPU ist mit dem Setting auch kühler. Kann das sein? Ich habe ganz bestimmt nichts dagegen...
Zum Vergrößern anklicken....
Naja, PCID hat schon Overhead, der durch das Deaktivieren wegfällt. Aber soviel eigentlich nicht... Ich hab mir aber auch nie drauf geachtet, wie sich das auf die Leistung auswirkt. Die CPU war für mich einfach immer bei weitem schnell genug, da fällt sowas nicht auf.
 
Das Restore verlief natürlich nicht linear, war ja klar. Aber es sind 79 Minuten zu etwas über 90 Minuten. Immerhin. Wenn ich nicht andauernd den gleichen Restore gemacht hätte, dann wäre mir das auch nicht aufgefallen...
 
Ach ja, restic ist jetzt beim Verify. Der Restore verlief ohne Fehler. Ich denke, wir können das Thema als gelöst betrachten. :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben