Proxmox Freezes mit ZFS Kernel Panic bei Hetzner mit Kernel > 6.8.12

[UnknownNPC]

Hallo,
ich betreibe einen Proxmox Server bei Hetzner(AMD Ryzen 5950X, ZFS als Dateisystem) und habe seite Kernel Version 7.0 aufwärts Stabilitätsprobleme.

Ich habe das System bereits auf Hardwarefehler geprüft, konnte dabei aber nichts finden.
Ich hatte das System nun eine lange Zeit auf Kernel 6.8.12-23-pve gepinnt und gestern testweise den neuen Kernel installiert. Heute war das System wieder freezed und ich hatte folgenden Fehler im Journal:

Sep 15 11:39:40 kernel: PANIC at btree.c:1867:zfs_btree_remove()
Sep 15 11:39:40 kernel: VERIFY3P(zfs_btree_find(tree, value, &where), !=, NULL) failed (0000000000000000 != 0000000000000000)

In anderen Fällen fand sich im Journal jedoch nichts Auffälliges, was auf die Ursache hindeuten würde. Um das System wieder in einen lauffähigen Zustand zu bringen bleibt mir nur der Hard Reset.

Hat jemand von euch eine Idee woran das liegen könnte und warum ausschließlich Kernel 7.0 aufwärts betroffen ist?

Danke schon mal für eure Hilfe!

 

[Bu66as]

Die eine VERIFY-Zeile allein bringt leider wenig, bei den btree-Assertions steht die Info im Stacktrace direkt darunter (welcher Thread, txg_sync/zvol/metaslab...). Kannst du den kompletten Block aus dem Journal nachreichen, also alles ab PANIC at btree.c bis zum Ende des Traces? Falls das System dabei komplett einfriert und nichts mehr auf Platte landet: kernel.panic=10 setzen, dann rebootet die Kiste nach dem Panic statt hängen zu bleiben, und das persistente Journal hat meist noch den Rest.

Mit dem neuen Kernel kommt in der Regel auch ein neues zfs-Modul mit. Vergleich mal modinfo zfs | grep ^version unter beiden Kernels, gut möglich dass nicht der Kernel die relevante Variable ist sondern der OpenZFS-Sprung. Und schau was zum Zeitpunkt des Freeze lief, Scrub, Snapshot-Löschen/Replikation oder autotrim. Die btree-Panics sitzen fast immer in Space-Map-/range_tree-Operationen, die Korrelation mit dem Job bringt dich schneller weiter als Raten. Wenn zpool get feature@block_cloning <pool> active zeigt, würd ich das testweise über zfs_bclone_enabled=0 rausnehmen.

Die Freezes ohne irgendwas im Journal sind btw vllt eine ganz andere Baustelle. Bei Ryzen-Servern bei Hetzner war das bei mir schon zweimal C-State-Gezappel, mit C6 aus bzw. processor.max_cstate=1 an der Kernel-Cmdline war dann Ruhe.

 

[UnknownNPC]

Danke für die schnelle Antwort. Im Journal ist leider nicht mehr der komplette Stacktrace da das FS scheinbar danach nichts mehr schreiben konnte. Ich werde jetzt erstmal die C-States wie von dir genannt einschränken und dann bezüglich des ZFS Problems schauen falls es dann noch noch auftritt.