Dauer zpool replace

jacky0815

Renowned Member
Aug 26, 2010
32
0
71
Hallo zusammen,

kann mir jemand sagen, ob es normal ist, dass ein zpool replace Tage dauert? Zugegeben war der letzte Ausfall einer HDD schon Jahre her, aber ich bin mir sicher, dass es damals nur Stunden gedauert hat.

Code:
  pool: rpool
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Wed Mar  5 17:54:07 2025
        9.69T / 43.5T scanned at 158M/s, 1.84T / 38.1T issued at 29.9M/s
        463G resilvered, 4.82% done, 14 days 17:49:24 to go
 
Das kommt drauf an... immerhin müssen auch 43.5TB gesannt werden und das auf HDD's? Das kann dauern.

Gib mir doch mal den Output von

Code:
zpool status

und

Code:
zpool list -v
 
  • Like
Reactions: news
Hi, beides schaut soweit OK aus, würd ich sagen.

Bash:
# zpool status
  pool: rpool
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Wed Mar  5 17:54:07 2025
        9.69T / 43.5T scanned at 141M/s, 2.31T / 38.1T issued at 33.5M/s
        560G resilvered, 6.06% done, 12 days 22:56:07 to go
config:

        NAME                                                      STATE     READ WRITE CKSUM
        rpool                                                     DEGRADED     0     0     0
          raidz1-0                                                DEGRADED     0     0     0
            ata-HGST_HUH721010ALE604_1EKD42BZ-part3               ONLINE       0     0     0
            ata-HGST_HUH721010ALE604_1EKA1T0Z-part3               ONLINE       0     0     0
            ata-HGST_HUH721010ALE604_1EKEP3RZ-part3               ONLINE       0     0     0
            ata-HGST_HUH721010ALE604_1EKGW9GZ-part3               ONLINE       0     0     0
            ata-HGST_HUH721010ALE604_1SGNBKEZ-part3               ONLINE       0     0     0
            replacing-5                                           DEGRADED     0     0     0
              1515766499246825959                                 UNAVAIL      0     0     0  was /dev/disk/by-id/ata-HGST_HUH721010ALE604_1EKDV3YZ-part3
              ata-WDC_WUS721010ALE6L4_VH1V1ZMM-part3              ONLINE       0     0     0  (resilvering)
        logs
          mirror-1                                                ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4GJNFMN706577-part1  ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4GJNFMN706578-part1  ONLINE       0     0     0
        cache
          nvme0n1p2                                               ONLINE       0     0     0
          nvme1n1p2                                               ONLINE       0     0     0

errors: No known data errors

Bash:
# zpool list -v
NAME                                                       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
rpool                                                     54.6T  43.6T  10.9T        -         -    41%    79%  1.00x  DEGRADED  -
  raidz1-0                                                54.6T  43.6T  10.9T        -         -    41%  79.9%      -  DEGRADED
    ata-HGST_HUH721010ALE604_1EKD42BZ-part3               9.10T      -      -        -         -      -      -      -    ONLINE
    ata-HGST_HUH721010ALE604_1EKA1T0Z-part3               9.10T      -      -        -         -      -      -      -    ONLINE
    ata-HGST_HUH721010ALE604_1EKEP3RZ-part3               9.10T      -      -        -         -      -      -      -    ONLINE
    ata-HGST_HUH721010ALE604_1EKGW9GZ-part3               9.10T      -      -        -         -      -      -      -    ONLINE
    ata-HGST_HUH721010ALE604_1SGNBKEZ-part3               9.10T      -      -        -         -      -      -      -    ONLINE
    replacing-5                                               -      -      -        -         -      -      -      -  DEGRADED
      1515766499246825959                                     -      -      -        -         -      -      -      -   UNAVAIL
      ata-WDC_WUS721010ALE6L4_VH1V1ZMM-part3              9.10T      -      -        -         -      -      -      -    ONLINE
logs                                                          -      -      -        -         -      -      -      -         -
  mirror-1                                                99.5G   684K  99.5G        -         -     0%  0.00%      -    ONLINE
    nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4GJNFMN706577-part1   100G      -      -        -         -      -      -      -    ONLINE
    nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4GJNFMN706578-part1   100G      -      -        -         -      -      -      -    ONLINE
cache                                                         -      -      -        -         -      -      -      -         -
  nvme0n1p2                                                854G   844G  10.1G        -         -     0%  98.8%      -    ONLINE
  nvme1n1p2                                                854G   844G  10.2G        -         -     0%  98.8%      -    ONLINE
 
43.5T scanned at 158M/s
Wenn das stabil so weitergeht...
Code:
~$ echo 43500000 / 158 | bc
275316
~$ echo 43500000 / 158 / 3600 | bc
76
...wären es nur noch drei Tage :-)


Andere Anmerkung: ein SLOG mit 100GB ist Unfug. Erstens werden dort nur SYNC-writes hinein getan, normale Schreibvorgänge profitieren von einem SLOG nicht.

Zweitens ist nur eine einzige Transaction-Group (TXG) zum Schreiben geöffnet, während eine zweite gerade weggeschrieben wird. Nach maximal 5 Sekunden wird "gewechselt".

In 5 Sekunden liefert ein 10 GBit/s Kabel maximal 1250 Megabytes an frischen Daten an. Mehr als 2.5 Gigabyte sind also niemals im SLOG abgespeichert. (Abgesehen vielleicht vom "Umschalt"-Moment, in dem eventuell eine alte, dritte TXG weggeräumt wird.) Ich würde daher höchstens 5 GB an Größe vorsehen. Der Rest ist schlicht verschenkt.

Oder generierst du lokal schneller Daten als mit 1.25 GB/s???


Sinnvoller ist ein "Special Device", das wirkt vollkommen anders...
 
Tatsächlich sinkt die Rate kontinuierlich ab und ist aktuell unter 140MB/sec gefallen.

Danke für die Hinweise zum SLOG usw. Mit einem "Sepcial Device" muss ich mich mal in Ruhe beschäftigen, höre ich zum ersten mal. Glaube im proxmox-Wiki war das damals zur Einrichtung noch nicht erklärt.
 
Tatsächlich sinkt die Rate kontinuierlich ab und ist aktuell unter 140MB/sec gefallen.
Dein einziges RaidZ-vdev liefert die IOPS einer einzigen Platte. Sobald der Kopf hin- und herfahren muss, bricht die Übertragungsrate drastisch ein. Das ist leider vollkommen normal.

Zum "Special Device" siehe auch:
 
  • Like
Reactions: mariol
@UdoB danke. Das mit dem Special Device [0] macht auf alle Fälle Sinn. Das spührt man im Betrieb! Ist auch recht flott eingerichtet. Aber der Vorteil ist nur für neu geschriebenen Daten gültig. Somit müsstest du die Daten weg kopieren und wieder zurück schieben. "zfs send/receive".

Grundsätzlich rate ich IMMER davon ab [1] RaidZ (ähnlich Raid5) zu verwenden. Das ist am langsamsten beim Resilvern. Bei Raid10 hast du einzelne Mirrors. Da funktioniert der Resilverprozess auch viel scheller. Und wenn dir beim Resilver bei RaidZ eine weitere HDD stirbt, wars das mit dem Pool. Bei Raid10 hast du immer Mirrors/Paare.

[0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_zfs_special_device
[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_zfs_raid_performance
 
Last edited:
Naja, RAID10 ist dann vom Plattenaufwand nochmal eine andere Nummer. Die VMs werden regelmäßig repliziert, von daher gibt es nochmal ein weitere Schicht bezüglich Ausfallsicherheit. Allerdings funktioniert das jetzt beim resilvering nicht mehr, das ist schon etwas doof.
Ich muss gestehen, der letzte HDD-Ausfall liegt Jahre zurück, von daher ist das kein Szenario was wir täglich üben und meiner Meinung nach ging es das letzte Mal wesentlich schneller (ein paar Stunden).
 
Naja, RAID10 ist dann vom Plattenaufwand nochmal eine andere Nummer. Die VMs werden regelmäßig repliziert, von daher gibt es nochmal ein weitere Schicht bezüglich Ausfallsicherheit. Allerdings funktioniert das jetzt beim resilvering nicht mehr, das ist schon etwas doof.
Ich muss gestehen, der letzte HDD-Ausfall liegt Jahre zurück, von daher ist das kein Szenario was wir täglich üben und meiner Meinung nach ging es das letzte Mal wesentlich schneller (ein paar Stunden).
Da hattest du vermutlich deutlich weniger Daten im Pool. ZFS weiß ja was belegt ist und resilvert auch nur die Menge. Jetzt ist das ja schon eine ganze Menge für so langsame HDDs.

P.S: das längste was ich einmal gesehen habe bei einem RaidZ2 waren 3 Monate. Da kamen täglich neue Daten hinzu und die Prio wurde damals geändert, damit man überhaupt noch schreiben konnte. Waren aber auch 26 x 16TB HDDs. (Nicht meine Idee gewesen ;) )
 
Last edited:
Vielen Dank nochmal, hat jetzt alles geklappt. Darf ich noch eine Frage an die Wissenden stellen? Wie groß sollte denn das special device sein? Ich lese da sehr unterschiedliche Werte im Netz. Ist ein kleines besser als keins oder sollte man schon eine bestimmte Größe einhalten, bevor man sich es überlegt.
Gleiche Frage wär beim Cache. SLOG habt ihr mir ja schon schön vorgerechnet, das habe ich auch so noch nicht gelesen, zumindest damals bei der Einrichtung nicht.

Vielen Dank
 
Naja, RAID10 ist dann vom Plattenaufwand nochmal eine andere Nummer.
Kommt darauf an.
Du kannst deine VMs auch auf einen NVME mirror legen und die Daten auf ein RAIDZ2 dataset.
Dann hast du
- blitzschnelle VMs
- viel Speicher für Daten
- Kein Problem mit Fragmentierung
- Dadurch viel schnellere resilver
- Daten profitieren von einer besseren Performance und Kompression, weil sie nicht mehr auf starren 16k liegen, sondern auf einem flexiblen record size.
- Zudem ist dir vielleicht aufgefallen, dass eine (gefüllte) 1TB RAW VM disk auf deinem 16k zvol RAIDZ1 pool aus 6 Platten seltsamerweise mehr als 1TB Speicher benötigt.

Viele User verstehen pool geometry und padding nicht. Darum raten alle zwingend zu mirrors bei blockstorage wie VMs!
Gleiches gilt für SLOG und L2ARC. Wer sich unsicher ist, besser mal ohne starten und dann anfangen mit tunen. Bei einem sauberen pool brauchen viele gar keine Extras :)
 
Last edited:
Vielen Dank nochmal, hat jetzt alles geklappt. Darf ich noch eine Frage an die Wissenden stellen? Wie groß sollte denn das special device sein? Ich lese da sehr unterschiedliche Werte im Netz. Ist ein kleines besser als keins oder sollte man schon eine bestimmte Größe einhalten, bevor man sich es überlegt.
Das Special Device sollte immer mindestens aus einem einfachen Mirror bestehen, gern auch 3Fach Mirror. Die SSDs können klein sein, aber sollten schnell schreiben können. Hohe Schreibperformance gibts aber erst ab größeren SSDs. Wenn du 2% vom Volumen hast bist du Safe unterwegs, meistens habe ich aber mehr, weil die Performanten NVMe halt schon von Haus aus größer sind.
Falls du noch irgendwo gebrauchte Optane NVMe findest, dann sind die Perfekt für Special Devices.
 
Hi, sehr interessant. Im Netz liest man etwas von 0,3% bis maximal 1%. Die Werte gehen sehr weit auseinander. Das ist leider alles sehr undurchsichtig und ein gutes Webinar über zfs sucht man vergebens.
Gebrauchte SSDs kommen nicht in Frage, da wir hier bei gewerbliche Anwendung in einem kleinen KMU sind.


Und noch eine Idee in den Raum geworfen: Wie wäre es mit einem RAID50 (also 2x RAIDZ-1 + stripe). Das wäre sicher ein Kompromiss den wir eingehen könnten, bezüglich Kapazität. Wäre sicherlich schneller als ein reines RAIDZ-1 bzw. -2, oder?

Gruß
 
Last edited:
Guten Morgen, für ZFS special device gibt es keinen Kompromiss. Ein Design könnte der von Dir beschriebene Pool schon sein, aber nur dahingehend, wenn man den Bereich der Metadaten auf SSD auslagert. Und wenn wir uns dann die Größen der Speichermedien anschauen, z.B Kingston dc600m mit 960 MB, und man selbst mal ganz großzügig 2,5% Bedarf annimmt, dann liegt man bei rund 38,4 Terabyte Nutzungkapazität auf den HDDs. Ich selbst rechne einfach mit den Größen der zu beschaffenden SSDs, und damit liege ich sehr gut. Darüber hinaus ist auch die TWB dementsprechend höher, je größer das Medium ist. Man darf nicht vergessen, die Schreiblast auf den SSDs ist auch entsprechend vorhanden.
 
Last edited:
  • Like
Reactions: Johannes S
Was man mit einen VDEV ZFS Special Device nicht kann, es aus einen ZFS Pool wieder entfernen.
Aber man kann es Erweitern, z.B. als VDEV ZFS Special Device mit 3x Mirror oder als 2x Mirror - Stripe - 2x Mirror nutzen und natürlich auch gegen größere SSD ersetzen und nach dem resilvern, anschließend das VDEV ZFS Special Device vergrößern.
NVMe sind nicht von Nöten und vergleichsweise teurer.
 
Ich hätte jetzt ganz pragmatisch 2x NVMe SSDs mit 2TB genommen, partitoniert und diese sowohl als Special Device (mirror), als auch als L2ARC (stripe) verwendet. Der L2ARC funktioniert jetzt schon recht gut, da wir überwiegens Lesezugriffe haben, natürlich ist schneller immer besser.
 
Welche NVMe sind im Gespräch?
mit PLP und DRAM Cache und 3-4 PByte TWB?

Ich nutze "größere" SSD in Verbindung mit HDD unter Proxmox VE mit ZFS als Fileserver und 6 Partitionen:
1) Bios Boot,
2) EFI Boot,
3) ZFS Mirror: zfs pool rpool,
4) ZFS Mirror: zfs special device,
5) ZFS Mirror: zfs zil/slog und
6) ZFS Stripe: zfs cache für jeweils den HDD-Pool.
 
Last edited:
  • Like
Reactions: Johannes S