PVE instabil wg. defekter Festplatte eines zfspools

pvenewbie

New Member
Mar 19, 2025
6
0
1
Sehr geehrte Community,

heute hatten wir ein merkwürdiges Phänomen, da ich wenig PVE Erfahrung habe könnt ihr mir da ggf. weiterhelfen.
Wir betreiben einen mehr oder minder unproduktiven PVE Host an einem Standort, der sich wie folgt aufbaut:
2x 250GB Sata SSDs Raid1 --> PVE OS
6x Sata SSD --> Raidz10 für VMs
10x 4TB HDDs --> Raidz10 Massenspeicher

Heute früh habe ich einer VM ein 8TB Laufwerk zugewiesen und diese auf dem Massenspeicherpool abgelegt.
Dann wurden Daten auf das 8TB Laufwerk übertragen.
Ab Mittag wurde dann der PVE Host instabil, es gab immer wieder kurze Aussetzer beim Versuch das WebUI zu bedienen oder sich per SSH zu verbinden.
Die 2 dort laufenden VMs waren ebenfalls immer wieder kurz unerreichbar.
Ich hatte dann den PVE Host auf gut Glück einmal neugestartet, nur um dann ewig in einer schwarzen Maske zu hängen in der PVE mir immer wieder anzeigt das eine bestimmte Platte defekt sei. Siehe Anhang.
Soweit so gut...
Nach 20 Minuten war die Kiste dann wieder hochgefahren und das WebUI wieder erreichbar.
Die vormals defekte HDD wurde als Funktionierend und operabel angezeigt - Merkwürdig.
Aber nach 5 Minuten ging das gleiche Thema wieder von vorne los, das WebUI reagierte nicht mehr richtig usw.
Ich hab die HDD also physisch am Host entfernt und via zpool offline poolname HDD-ID offline gestellt.
Danach war alles wieder normal und blieb es auch.
Ich hatte eine passende 4TB HDD vor Ort, deshalb habe ich diese gleich via zpool replace ersetzt, seit dem läuft der Host auch wieder ganz normal.

Meine Fragen dazu wären die folgenden:

Warum führt der "Defekt" einer HDD eines zfspools der prinzipiell mit dem PVE Host OS nichts zu tun hat dazu, das das ganze System instabil wird?
Und zweitens, kann der Vorgang nicht theoretisch auch automatisiert erfolgen wenn ich die Festplatte physisch entferne und eine neue einsetze, wieso muss ich die Platte erst offline schalten und dann replacen via shell?
Mein Wunschszenario wäre das der Host normal funktioniert auch wenn eine HDD kaputt geht und das der resilvering Prozess automatisch passiert wenn die defekte Platte physisch ersetzt wurde.

Vielen Dank und viele Grüße,
pvenewbie
 

Attachments

  • shared image.jpg
    shared image.jpg
    401.4 KB · Views: 13
Warum führt der "Defekt" einer HDD eines zfspools der prinzipiell mit dem PVE Host OS nichts zu tun hat dazu, das das ganze System instabil wird?
Sollte es eigentlich nicht. Vielleicht war da noch ein anderes Problem. RAM? Kontroller? Netzteil?
Heute früh habe ich einer VM ein 8TB Laufwerk zugewiesen
Offtopic, aber wenn du einer VM eine Laufwerk zuweist, liegen die Daten danach auf blockstorage mit einer fixen volblocksize (16k).
Das hat einige Nachteile gegenüber einem Dataset mit einer variablen max record size.
Und zweitens, kann der Vorgang nicht theoretisch auch automatisiert erfolgen wenn ich die Festplatte physisch entferne und eine neue einsetze, wieso muss ich die Platte erst offline schalten und dann replacen via shell?
Sollten wir mal einen feature request machen. Finde auch das sollte automatisiert, oder zumindest im GUI möglich sein, statt in der Shell. Zudem geht auch noch Grub gerne vergessen bei boot pools. Das könnte denke ich auch im GUI integriert werden.
 
Sollte es eigentlich nicht. Vielleicht war da noch ein anderes Problem. RAM? Kontroller? Netzteil?

Offtopic, aber wenn du einer VM eine Laufwerk zuweist, liegen die Daten danach auf blockstorage mit einer fixen volblocksize (16k).
Das hat einige Nachteile gegenüber einem Dataset mit einer variablen max record size.

Sollten wir mal einen feature request machen. Finde auch das sollte automatisiert, oder zumindest im GUI möglich sein, statt in der Shell. Zudem geht auch noch Grub gerne vergessen bei boot pools. Das könnte denke ich auch im GUI integriert werden.

Moin, danke für dein Feedback.

Einen anderen Defekt kann ich per se erst einmal nicht ausschließen, aber halte ich aufgrund des Verhaltens für unwahrscheinlich.
Mit dem Entfernen der defekten Platte lief das System sofort wieder stabil und auch nach dem Einsetzen der Ersatzplatte im selben Slot ist alles iO geblieben.

Zum Thema Block storage und volblocksize müsstest du mich abholen, da bin ich nicht im Thema.

Feature requests stellt man wo?

Grüße vom Sofa,

pvenewbie
 
Last edited:
Einen anderen Defekt kann ich per se erst einmal nicht ausschließen, aber halte ich aufgrund des Verhaltens für unwahrscheinlich.
Würde das Gegenteil behaupten. Eine ZFS mirror kann es nicht egaler sein, ob eine Platte ausfällt. Theoretisch zumindest ;)
Zum Thema Block storage und volblocksize müsstest du mich abholen, da bin ich nicht im Thema.
zvols (bei proxmox local-zfs) sind blockstorage (mit einer fixen volblocksize) per default 16k.
datasets (bei Proxmox local) sind datasets (mit einer max record size) per default 128k.
Betonung auf max. Es ist also variabel. Legst du eine 8GB movie auf ein blockstorage, wird er in 16k chunks geteilt.
Schreibst du eine 4k Datei, wird ein 16k chunk neu geschrieben.
Bei Dataset hat eine 4k Datei ein 4k record, eine 256k hat zwei 128k records (oder noch besser, du änderst record size auf 1MiB oder 16MiB).

TLDR: Hat Auswirkungen auf metadata performance, Kompression, storage efficiency bei RAIDZ, rw amplifiaction und vielen mehr.

https://github.com/jameskimmel/opinions_about_tech_stuff/blob/main/ZFS/Beginners guide to ZFS

https://github.com/jameskimmel/opin...main/ZFS/The problem with RAIDZ.md#conclusion
 
  • Like
Reactions: Johannes S
Hi, das ist ein ganz normales Verhalten von drehendem Rost. Wenn eine HDD langsam kaputt geht, aber noch nicht so viele Dehler hat, dass diese aussortiert wird, hast du ständig Lese oder Write retry‘s welche extrem I/O Delay erzeugen.
Kann man nur mit gutem Monitoring und proaktivem Disk tauschen, vermieden werden.
 
  • Like
Reactions: Johannes S
Sollte bei einem ZFS mirror da nicht einfach von der anderen Disk gelesen werden?
Oder bleibt einfach eine Leseoperation stecken und die verzögert dann alles?
 
Solange die Disk Daten liefert, aber diese nicht konsistent sind macht er für den Block immer wieder retries und erst nach Timeout gibt die Disk einen Fehler aus und ZFS liest vom anderen Member. Die Technik ist aber in der Disk und ZFS wartet brav.
 
  • Like
Reactions: IsThisThingOn
Kann man den Timeout definieren wie lang zfs eine Disk anfragt bis plausible Daten kommen (oder auch eben nicht kommen)?
Wenn ja ist das sinnvoll?
 
Kann man den Timeout definieren wie lang zfs eine Disk anfragt bis plausible Daten kommen (oder auch eben nicht kommen)?
Wenn ja ist das sinnvoll?
Nein, weil ZFS eine Anfrage an eine Disk macht und die Disk kann ja einfach auch mal nur etwas langsamer sein. Deshalb wartet jedes System immer brav auf die Disk. Bei dem schleichenden Tod, versucht die Elektronik auf der Disk, die Daten immer wieder zu lesen, und muss natürlich für jede Wiederholung auf eine ganze Umdrehung warten. Daher entstehen dann halt Warteschlangen und alles wird langsam.
Bei Hardware Raid Controllern gab es extra dafür ein Feature, wo Disks mit bestimmten Lesefehlern direkt aussortiert werden und die Spare Disk genutzt wird. Aber auch da hatte man das oft schon gespürt, bis zum Aussortieren.

Das Thema erledigt sich aber automatisch mit der Nutzung von Flash Speicher.