With the update of Unraid to 7.0.1 I took some SSDs I had lying around and created a ZFS pool. Since I upgraded to 7.1.2 my server becomes unresponsive after a few hours and the ZFS Master plugin doesn't show my pools.

 

I can still ssh into the server but as soon as I try to cd into /mnt the shell becomes unresponsive and a zfs list hangs as well. I have to reboot with the terminal command reboot and the server comes up again without problems and everything looks healthy for a couple of hours.

Any pointers what might be the issue? Maybe spindown settings on the ssd (which I haven't checked yet)?

 

Cheers

 

hydra-diagnostics-20250519-1043.zip

I assume the diags are after rebooting? If yes, enable the syslog server and post that after it happens again.

You're partially right. I downloaded the diagnostics when the issue presented itself again, that's why the zfs-info.txt inside the system folder is empty I guess, but I didn't enable the syslog server. I'll reboot now and enable it and report back in a few hours 🙂

 

Thank you very much

I was looking at the end of the syslog and there's nothing zfs related there, but taking a second look, there's a call trace when the pool is first mounted:

 

May 18 10:32:08 Hydra emhttpd: shcmd (103): mkdir -m 0666 -p /mnt/cache
May 18 10:32:08 Hydra emhttpd: /sbin/blkid /dev/nvme0n1p1 2>&1
May 18 10:32:08 Hydra emhttpd: /dev/nvme0n1p1: LABEL="cache" UUID="1542324243434126461" UUID_SUB="17686516482941424722" BLOCK_SIZE="4096" TYPE="zfs_member"
May 18 10:32:08 Hydra emhttpd: shcmd (104): /usr/sbin/zpool import -f -m -N -o autoexpand=on  -d /dev/nvme0n1p1 1542324243434126461 cache
May 18 10:32:08 Hydra kernel: PANIC: zfs: adding existent segment to range tree (offset=405352000 size=14000)
May 18 10:32:08 Hydra kernel: Showing stack for process 8636
May 18 10:32:08 Hydra kernel: CPU: 5 UID: 0 PID: 8636 Comm: z_metaslab Tainted: P           O       6.12.24-Unraid #1
May 18 10:32:08 Hydra kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE
May 18 10:32:08 Hydra kernel: Hardware name: Micro-Star International Co., Ltd. MS-7B98/Z390-A PRO (MS-7B98), BIOS 1.C0 10/10/2020
May 18 10:32:08 Hydra kernel: Call Trace:
May 18 10:32:08 Hydra kernel: <TASK>
May 18 10:32:08 Hydra kernel: dump_stack_lvl+0x47/0x70
May 18 10:32:08 Hydra kernel: vcmn_err+0x9d/0xe0 [spl]
May 18 10:32:08 Hydra kernel: ? sysvec_apic_timer_interrupt+0xa0/0xc0
May 18 10:32:08 Hydra kernel: ? asm_sysvec_apic_timer_interrupt+0x16/0x20
May 18 10:32:08 Hydra kernel: ? bt_grow_leaf+0xc3/0xe0 [zfs]
### [PREVIOUS LINE REPEATED 1 TIMES] ###
May 18 10:32:08 Hydra kernel: ? zfs_btree_insert_leaf_impl+0x21/0x50 [zfs]
May 18 10:32:08 Hydra kernel: zfs_panic_recover+0x70/0x90 [zfs]
May 18 10:32:08 Hydra kernel: zfs_range_tree_add_impl+0x92/0x490 [zfs]
May 18 10:32:08 Hydra kernel: space_map_load_callback+0x61/0x80 [zfs]
May 18 10:32:08 Hydra kernel: space_map_iterate+0x2d1/0x330 [zfs]
May 18 10:32:08 Hydra kernel: ? __pfx_space_map_load_callback+0x10/0x10 [zfs]
May 18 10:32:08 Hydra kernel: space_map_load_length+0x91/0xd0 [zfs]
May 18 10:32:08 Hydra kernel: metaslab_load+0x32a/0x6c0 [zfs]
May 18 10:32:08 Hydra kernel: ? task_done+0x51/0x80 [spl]
May 18 10:32:08 Hydra kernel: metaslab_preload+0x4f/0xa0 [zfs]
May 18 10:32:08 Hydra kernel: taskq_thread+0x374/0x4d0 [spl]
May 18 10:32:08 Hydra kernel: ? __pfx_default_wake_function+0x10/0x10
May 18 10:32:08 Hydra kernel: ? __pfx_taskq_thread+0x10/0x10 [spl]
May 18 10:32:08 Hydra kernel: kthread+0xec/0x100
May 18 10:32:08 Hydra kernel: ? __pfx_kthread+0x10/0x10
May 18 10:32:08 Hydra kernel: ret_from_fork+0x21/0x40
May 18 10:32:08 Hydra kernel: ? __pfx_kthread+0x10/0x10
May 18 10:32:08 Hydra kernel: ret_from_fork_asm+0x1a/0x30
May 18 10:32:08 Hydra kernel: </TASK>

 

Since there's no fsck for zfs, I would recommend backing up and recreating that pool.

Thanks @JorgeB,

 

I configured the share to move everything off the cache nvme, and after multiple forced restarts mover did it's thing. Right now I destroyed the pool, removed the cache share and rebooted from the gui. Looks promising. The array stopped and the server rebooted without a hitch. Searching in the syslog I can't find a panic anymore.

 

Fingers crossed that was the problem.

 

Thank you very much!

Approaching 20 hours right now of uninterrupted responsive uptime, performing a parity check and giving the server additional work to tickle it a little bit more. With certainty you found the culprit. Thanks again. I marked it a solved. 🙂