ZFS Panic

DocMAX

Member
Jan 30, 2023
143
6
18
Bremen
Leute seit heute friert mein Proxmox irgendwie ständig ein. Hab das hier gefunden.
Ne idee was los ist? Hab 2 NVME + 1 SDD in einem zpool. (Kein ZRAID)

Code:
[Sa Feb 10 23:02:31 2024] veth0a19b2d (unregistering): left promiscuous mode
[Sa Feb 10 23:02:31 2024] br-2a9c11c83066: port 1(veth0a19b2d) entered disabled state
[Sa Feb 10 23:02:34 2024] VERIFY0(0 == P2PHASE(asize, 1ULL << vd->vdev_ashift)) failed (0 == 1024)
[Sa Feb 10 23:02:34 2024] PANIC at metaslab.c:5344:metaslab_free_concrete()
[Sa Feb 10 23:02:34 2024] Showing stack for process 1024
[Sa Feb 10 23:02:34 2024] CPU: 11 PID: 1024 Comm: z_wr_int_0 Tainted: P           OE      6.5.11-7-pve #1
[Sa Feb 10 23:02:34 2024] Hardware name: ASUSTeK COMPUTER INC. MINIPC PN52/PN52, BIOS 11800 09/07/2022
[Sa Feb 10 23:02:34 2024] Call Trace:
[Sa Feb 10 23:02:34 2024]  <TASK>
[Sa Feb 10 23:02:34 2024]  dump_stack_lvl+0x48/0x70
[Sa Feb 10 23:02:34 2024]  dump_stack+0x10/0x20
[Sa Feb 10 23:02:34 2024]  spl_dumpstack+0x29/0x40 [spl]
[Sa Feb 10 23:02:34 2024]  spl_panic+0xfc/0x120 [spl]
[Sa Feb 10 23:02:34 2024]  metaslab_free_concrete+0x287/0x290 [zfs]
[Sa Feb 10 23:02:34 2024]  ? __submit_bio+0xb3/0x1c0
[Sa Feb 10 23:02:34 2024]  metaslab_free_impl+0xc1/0x110 [zfs]
[Sa Feb 10 23:02:34 2024]  metaslab_free_dva+0x61/0x90 [zfs]
[Sa Feb 10 23:02:34 2024]  metaslab_free+0x11e/0x1b0 [zfs]
[Sa Feb 10 23:02:34 2024]  zio_free_sync+0x11d/0x130 [zfs]
[Sa Feb 10 23:02:34 2024]  zio_free+0xd3/0x110 [zfs]
[Sa Feb 10 23:02:34 2024]  dsl_free+0x11/0x20 [zfs]
[Sa Feb 10 23:02:34 2024]  dsl_dataset_block_kill+0x4b2/0x4e0 [zfs]
[Sa Feb 10 23:02:34 2024]  dbuf_write_done+0x19d/0x1e0 [zfs]
[Sa Feb 10 23:02:34 2024]  arc_write_done+0xaa/0x550 [zfs]
[Sa Feb 10 23:02:34 2024]  ? mutex_lock+0x12/0x50
[Sa Feb 10 23:02:34 2024]  zio_done+0x28c/0x10b0 [zfs]
[Sa Feb 10 23:02:34 2024]  ? srso_alias_return_thunk+0x5/0x7f
[Sa Feb 10 23:02:34 2024]  ? kfree+0x78/0x120
[Sa Feb 10 23:02:34 2024]  ? srso_alias_return_thunk+0x5/0x7f
[Sa Feb 10 23:02:34 2024]  zio_execute+0x8b/0x130 [zfs]
[Sa Feb 10 23:02:34 2024]  taskq_thread+0x282/0x490 [spl]
[Sa Feb 10 23:02:34 2024]  ? __pfx_default_wake_function+0x10/0x10
[Sa Feb 10 23:02:34 2024]  ? __pfx_zio_execute+0x10/0x10 [zfs]
[Sa Feb 10 23:02:34 2024]  ? __pfx_taskq_thread+0x10/0x10 [spl]
[Sa Feb 10 23:02:34 2024]  kthread+0xf2/0x120
[Sa Feb 10 23:02:34 2024]  ? __pfx_kthread+0x10/0x10
[Sa Feb 10 23:02:34 2024]  ret_from_fork+0x47/0x70
[Sa Feb 10 23:02:34 2024]  ? __pfx_kthread+0x10/0x10
[Sa Feb 10 23:02:34 2024]  ret_from_fork_asm+0x1b/0x30
[Sa Feb 10 23:02:34 2024]  </TASK>
[Sa Feb 10 23:02:43 2024] br-2a9c11c83066: port 1(veth3847179) entered blocking state
[Sa Feb 10 23:02:43 2024] br-2a9c11c83066: port 1(veth3847179) entered disabled state
[Sa Feb 10 23:02:43 2024] veth3847179: entered allmulticast mode
[Sa Feb 10 23:02:43 2024] veth3847179: entered promiscuous mode
 
zfs_recover=1 als modul parameter macht auch panic. nur import -o readonly=on zpool hat geklappt.
 
Last edited:
Also ich habe ein ganz miesen Log. Die Samsung 870 QVO scheint 6.0gb/s nicht mitmachen zu wollen.
Hab nun die Kernel Flags "pcie_aspm=off libata.force=noncq libata.force=3.0" gesetzt.
Jetzt ist Ruhe, läuft aber nur auf 3.0gb/s. Ich glaube das kann ich bei Samsung nicht reklamieren.

Hat noch jemand ne Idee oder das selbe Laufwerk ohne Probleme?

Edit: Mein SATA Controller sind:
07:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 81)
07:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 81)

Vielleicht macht der Probleme?

Code:
Feb 11 22:51:31 pve kernel: ata2.00: Enabling discard_zeroes_data
Feb 11 22:52:21 pve kernel: ata2.00: exception Emask 0x0 SAct 0x1c SErr 0xc0000 action 0x6 frozen
Feb 11 22:52:21 pve kernel: ata2: SError: { CommWake 10B8B }
Feb 11 22:52:21 pve kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Feb 11 22:52:21 pve kernel: ata2.00: cmd 61/10:10:10:0a:00/00:00:00:00:00/40 tag 2 ncq dma 8192 out
                                     res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Feb 11 22:52:21 pve kernel: ata2.00: status: { DRDY }
Feb 11 22:52:21 pve kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Feb 11 22:52:21 pve kernel: ata2.00: cmd 61/10:18:10:74:c0/00:00:d1:01:00/40 tag 3 ncq dma 8192 out
                                     res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Feb 11 22:52:21 pve kernel: ata2.00: status: { DRDY }
Feb 11 22:52:21 pve kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Feb 11 22:52:21 pve kernel: ata2.00: cmd 61/10:20:10:76:c0/00:00:d1:01:00/40 tag 4 ncq dma 8192 out
                                     res 40/00:01:06:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Feb 11 22:52:21 pve kernel: ata2.00: status: { DRDY }
Feb 11 22:52:21 pve kernel: ata2: hard resetting link
Feb 11 22:52:21 pve kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Feb 11 22:52:21 pve kernel: ata2.00: supports DRM functions and may not be fully accessible
Feb 11 22:52:21 pve kernel: ata2.00: supports DRM functions and may not be fully accessible
Feb 11 22:52:21 pve kernel: ata2.00: configured for UDMA/133
Feb 11 22:52:21 pve kernel: ata2: EH complete
Feb 11 22:52:21 pve kernel: ata2.00: Enabling discard_zeroes_data
Feb 11 22:52:22 pve kernel: ata2.00: exception Emask 0x10 SAct 0x100400 SErr 0x0 action 0x6 frozen
Feb 11 22:52:22 pve kernel: ata2.00: irq_stat 0x08000000, interface fatal error
Feb 11 22:52:22 pve kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Feb 11 22:52:22 pve kernel: ata2.00: cmd 61/08:50:00:28:00/00:00:24:00:00/40 tag 10 ncq dma 4096 out
                                     res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error)
Feb 11 22:52:22 pve kernel: ata2.00: status: { DRDY }
Feb 11 22:52:22 pve kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Feb 11 22:52:22 pve kernel: ata2.00: cmd 61/08:a0:00:28:00/00:00:26:00:00/40 tag 20 ncq dma 4096 out
                                     res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error)
Feb 11 22:52:22 pve kernel: ata2.00: status: { DRDY }
Feb 11 22:52:22 pve kernel: ata2: hard resetting link
Feb 11 22:52:22 pve kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Feb 11 22:52:22 pve kernel: ata2.00: supports DRM functions and may not be fully accessible
Feb 11 22:52:22 pve kernel: ata2.00: supports DRM functions and may not be fully accessible
Feb 11 22:52:22 pve kernel: ata2.00: configured for UDMA/133
Feb 11 22:52:22 pve kernel: ata2: EH complete
Feb 11 22:52:22 pve kernel: ata2.00: Enabling discard_zeroes_data
Feb 11 22:52:53 pve kernel: ata2.00: exception Emask 0x0 SAct 0x80000 SErr 0x0 action 0x6 frozen
Feb 11 22:52:53 pve kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Feb 11 22:52:53 pve kernel: ata2.00: cmd 61/10:98:10:76:c0/00:00:d1:01:00/40 tag 19 ncq dma 8192 out
                                     res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Feb 11 22:52:53 pve kernel: ata2.00: status: { DRDY }
Feb 11 22:52:53 pve kernel: ata2: hard resetting link
Feb 11 22:52:54 pve kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Feb 11 22:52:54 pve kernel: ata2.00: supports DRM functions and may not be fully accessible
Feb 11 22:52:54 pve kernel: ata2.00: supports DRM functions and may not be fully accessible
Feb 11 22:52:54 pve kernel: ata2.00: configured for UDMA/133
Feb 11 22:52:54 pve kernel: ata2: EH complete
Feb 11 22:52:54 pve kernel: ata2.00: Enabling discard_zeroes_data
Feb 11 22:53:24 pve kernel: ata2: limiting SATA link speed to 3.0 Gbps
Feb 11 22:53:24 pve kernel: ata2.00: exception Emask 0x0 SAct 0x1000 SErr 0x0 action 0x6 frozen
Feb 11 22:53:24 pve kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Feb 11 22:53:24 pve kernel: ata2.00: cmd 61/10:60:10:76:c0/00:00:d1:01:00/40 tag 12 ncq dma 8192 out
                                     res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Feb 11 22:53:24 pve kernel: ata2.00: status: { DRDY }
Feb 11 22:53:24 pve kernel: ata2: hard resetting link
Feb 11 22:53:25 pve kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
Feb 11 22:53:25 pve kernel: ata2.00: supports DRM functions and may not be fully accessible
Feb 11 22:53:25 pve kernel: ata2.00: supports DRM functions and may not be fully accessible
Feb 11 22:53:25 pve kernel: ata2.00: configured for UDMA/133
Feb 11 22:53:25 pve kernel: ata2.00: device reported invalid CHS sector 0
Feb 11 22:53:25 pve kernel: ata2: EH complete
Feb 11 22:53:25 pve kernel: ata2.00: Enabling discard_zeroes_data
 
Last edited:
Naja, die QVO nutzt QLC NAND, also sehr sehr schlecht geeignet für Copy-on-Write Dateisysteme wie ZFS. Die kann dann beim Schreiben halt ganz schnell in die Knie gehen und wenn ich die Benchmarks richtig erinnere, dann liegt die Performance je nach Größe zwischen 40 und 80MB/s und damit lahmer als eine HDD beim sequentiellen Schreiben. Mal ganz abgesehen davon, dass sich der NAND auch noch um ein vielfaches schneller abnutzt, was auch nicht gerade toll ist bei dem krassen Overhead von ZFS.
 
Last edited:
Also ich habe ein ganz miesen Log. Die Samsung 870 QVO scheint 6.0gb/s nicht mitmachen zu wollen.
ALso, QLC Consumer SSDs solltest du niemals mit ZFS benutzen.
1. Ist das Ding mit ZFS extrem langsam
2. Das dind wird in kürzester Zeit kaputt geschrieben.

Mein Tip:
Wenn du ZFS nutzen willst, kauf dir vernünftige SSDs mit PLP (Dazu gibts viele Infos im Forum) oder nutze die QLC SSDs lieber mit LVM, Ext4 oder XFS. Dann lebt die deutlich länger.
 
Also die Warnungen finde ich nett gemeint. Aber ich hatte in der Vergangenheit immer solche Diskussionen "nehm bloss nicht dies und nehme bloss nicht das". Am Ende des Tages lief dann alles problemlos. Deshalb bin ich da etwas abgestumpft. Sehr hohe Geschwindigkeiten brauche ich nicht, wird ja auch immerhin auf alle Laufwerke verteilt.

Ich denke dass sich ZFS bei Fehlern melden wird - hat es auch getan. Aber jetzt mit libata.force=3.0 scheint alles viel viel besser zu laufen. Und ganz plötzlich beim Boot wird der Zpool auch VIEL schneller importiert. Solange das Laufwerk von heute auf morgen nicht ganz ausfällt würde ich fix die Daten wegschreiben.

Alles in allem schön schei.... dieses Laufwerk, aber als wirklich kaputt kann ich das bei Samsumg wie gesagt wohl nicht reklamieren.
Ich werde aber auf jedenfall beim nächsten Kauf die Tips zum Plattenkauf hier befolgen.
 
Aber nochmal: ZFS war sehr entäuschend!!! zfs_recover=1 hat nichts bewirkt!!! Das kann jawohl nicht wahr sein!
 
Aber nochmal: ZFS war sehr entäuschend!!! zfs_recover=1 hat nichts bewirkt!!! Das kann jawohl nicht wahr sein!

Also..., wenn die Hardware keinerlei Daten mehr liefert, kann die beste Software nichts mehr retten ;-)

Ich sehe oben auch gar nichts zur Topologie. Wie ist (war?) der Pool denn aufgebaut?
 
Aber nochmal: ZFS war sehr entäuschend!!! zfs_recover=1 hat nichts bewirkt!!! Das kann jawohl nicht wahr sein!
Lese dich noch mal in ZFS ein und warum Consumer-SSDs nichts in einem wie auch immer erstellten ZFS-Pool zu suchen haben. Es geht einfach nicht zuverlässig... ZFS ist mehr ein "Enterprise-RAID-Dateisystem-Software-Controller"... das will dann eben auch Enterprise Hardware (Datenträger, ECC-Speicher haben)....
 
Also..., wenn die Hardware keinerlei Daten mehr liefert, kann die beste Software nichts mehr retten ;-)

Ich sehe oben auch gar nichts zur Topologie. Wie ist (war?) der Pool denn aufgebaut?

Sieht/sah so aus:

Code:
root@pve:~# zpool status zpool
  pool: zpool
 state: ONLINE
config:

        NAME                                                                           STATE     READ WRITE CKSUM
        zpool                                                                          ONLINE       0     0     0
          nvme-nvme.1dee-32313137303635343031343036-424957494e20535344-00000001-part4  ONLINE       0     0     0
          nvme-eui.e8238fa6bf530001001b448b4edde27a                                    ONLINE       0     0     0
          wwn-0x5002538f41104c52                                                       ONLINE       0     0     0

errors: No known data errors

Jetzt schon eine Weile in Benutztung, da sollten die 0 Fehler erstmal ausreichen für Consumer Platten.
 
Sieht/sah so aus:
Okay. Also Platzmaximierung, keinerlei Redundanz. Wenn ein Device ausfällt sind alle Daten wech und es gibt dann auch rein gar keine Erfolg versprechende Desaster-Recovery-Strategie. Den realen Datenverlust kann man ja über hinreichend häufige Backups begrenzen.

Allerdings erscheint mir ein System mit Redundanz Nerven schonender ;-)
 
  • Like
Reactions: Dunuin
ja, es laufen häufig Backups, deshalb habe ich mich für Platzmaximierung entschieden. Es sind 1GB, 2GB, 4GB Platten, deshalb sehr ungünstig für z.B. Raid-Z.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!