ZFS Kernel panic with zfs destroy on snapshot

bæros · 2025-12-10T11:37:30+0000

Hello everyone,

I was going through some old ZFS snapshots after I stumbled on a particular snapshot that I could not delete:

Code:

# zfs destroy -v zroot/jails/mantis@monthly-2025-07-01_05.30.01--6m
will destroy zroot/jails/mantis@monthly-2025-07-01_05.30.01--6m
Read from remote host arthur.fritz.box: Connection reset by peer
Connection to arthur.fritz.box closed.
client_loop: send disconnect: Broken pipe

This is reproducible. Not only is the SSH connection terminated or sshd killed but the kernel panics and reboots:

Code:

Dec 10 12:23:36 arthur savecore[1666]: reboot after panic: Solaris(panic): zfs: rt={spa=zroot vdev_guid=1996288907895677832 ms_id=73 ms_freeing}: adding segment (offset=12407e7000 size=1000) overlapping with existing one (offset=1240
Dec 10 12:23:36 arthur savecore[1666]: writing core to /var/crash/vmcore.6

It is a mirrored pool with no errors:

Code:

# zpool status
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0B in 00:09:41 with 0 errors on Wed Dec 10 02:09:41 2025
config:

        NAME        STATE     READ WRITE CKSUM
        zroot           ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            ada0p4  ONLINE       0     0     0
            ada1      ONLINE       0     0     0

errors: No known data errors

Code:

chris@arthur ~> uname -r
15.0-RELEASE
chris@arthur ~> freebsd-version -kru
15.0-RELEASE
15.0-RELEASE
15.0-RELEASE

Any ideas? Is it a hardware defect unnoticed by ZFS?

Best,
Chris

T-Daemon · 2025-12-10T14:26:50+0000

bæros said:
Any ideas? Is it a hardware defect unnoticed by ZFS?

Maybe run some test: sysutils/smartmontools

There is a PR: Bug 264127 - "zfs destroy" panic when destroying some snapshots but not all

The reporter resolved it as follows (comment # 6)

I found that the only snapshot in my zroot/var/mail dataset that didn't cause a kernel panic when destroyed was the most recently created. Destroying every snapshot in reverse order, from newest to oldest, was successful. After that, creating snapshots then destroying the oldest snapshot worked as expected.

cracauer@ · 2025-12-10T14:48:18+0000

Well, corrupted pool or not, a general kernel panic sounds like the wrong reaction.

There needs to be something like a "ZFS exception" that you can either catch or let fall through to a panic depending on what you need at that moment.

bæros · 2025-12-10T20:42:05+0000

cracauer@ said:
Well, corrupted pool or not, a general kernel panic sounds like the wrong reaction.

I agree. This should not happen.

T-Daemon said:
Maybe run some test: sysutils/smartmontools

There is a PR: Bug 264127 - "zfs destroy" panic when destroying some snapshots but not all

The reporter resolved it as follows (comment # 6)

Smartmontools shows no errors on both disks (SSD) and the daily scrub went fine as well. The issue seems similar, I first noticed when I tried to delete the filesystem with zfs destroy -r /opt/jails/mantis, which caused a reboot. Then I deleted the snapshots from newest to oldest, the single remaining oldest snapshot is the one that causes the kernel panic. So it cannot be resolved like in bug 264127.

I found a stacktrace in the messages:

Dec 10 12:23:36 arthur kernel: panic: Solaris(panic): zfs: rt={spa=zroot vdev_guid=1996288907895677832 ms_id=73 ms_freeing}: adding segment (offset=12407e7000 size=1000) overlapping with existing one (offset=12407e7000 size=1000)
Dec 10 12:23:36 arthur kernel: cpuid = 1
Dec 10 12:23:36 arthur kernel: time = 1765365759
Dec 10 12:23:36 arthur kernel: KDB: stack backtrace:
Dec 10 12:23:36 arthur kernel: #0 0xffffffff80bbe1ed at kdb_backtrace+0x5d
Dec 10 12:23:36 arthur kernel: #1 0xffffffff80b71576 at vpanic+0x136
Dec 10 12:23:36 arthur kernel: #2 0xffffffff80b71433 at panic+0x43
Dec 10 12:23:36 arthur kernel: #3 0xffffffff8225735f at vcmn_err+0xdf
Dec 10 12:23:36 arthur kernel: #4 0xffffffff8235a255 at zfs_panic_recover+0x55
Dec 10 12:23:36 arthur kernel: #5 0xffffffff82331cb5 at zfs_range_tree_add_impl+0x225
Dec 10 12:23:36 arthur kernel: #6 0xffffffff8232a710 at metaslab_free_concrete+0x140
Dec 10 12:23:36 arthur kernel: #7 0xffffffff8232bb5a at metaslab_free+0x18a
Dec 10 12:23:36 arthur kernel: #8 0xffffffff82436edc at zio_dva_free+0x1c
Dec 10 12:23:36 arthur kernel: #9 0xffffffff82431c68 at zio_execute+0x38
Dec 10 12:23:36 arthur kernel: #10 0xffffffff80bd4de2 at taskqueue_run_locked+0x182
Dec 10 12:23:36 arthur kernel: #11 0xffffffff80bd5fb2 at taskqueue_thread_loop+0xc2
Dec 10 12:23:36 arthur kernel: #12 0xffffffff80b2786b at fork_exit+0x7b
Dec 10 12:23:36 arthur kernel: #13 0xffffffff81050f3e at fork_trampoline+0xe