System information
| Type |
Version/Name |
| Distribution Name |
RedHat |
| Distribution Version |
9.7 |
| Kernel Version |
5.14.0-611.47.1.el9_7 |
| Architecture |
x86_64 |
| OpenZFS Version |
2.2.9-2 |
Describe the problem you're observing
System hangs when importing pool
Describe how to reproduce the problem
Unknown, machine seems to have crashed before this happened. log appruptly ends with a new "boot" line. In this boot I see a message about corrupt system.journal because of unclean shutdown and then when the zfs-import.service starts I see the stack trace posted below the first time.
I can import the pool in read-only mode just fine but so far I did not manage to recover the pool. SMART reports all good on the drives. No the nodes does not have ECC memory.
As the pool is rather big (for me) I would really like to recover it and not drop down to the backup from yesterday.
Include any warning/errors/backtraces from the system logs
kernel: VERIFY3(range_tree_space(smla->smla_rt) + sme->sme_run <= smla->smla_sm->sm_size) failed (537473024 <= 536870912)
kernel: PANIC at space_map.c:405:space_map_load_callback()
kernel: Showing stack for process 2234
kernel: CPU: 12 PID: 2234 Comm: zpool Kdump: loaded Tainted: P OE ------ --- 5.14.0-611.47.1.el9_7.x86_64 #1
kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X570 Phantom Gaming X, BIOS P3.20 06/15/2020
kernel: Call Trace:
kernel: <TASK>
kernel: dump_stack_lvl+0x34/0x48
kernel: spl_panic+0xd1/0xf6 [spl]
kernel: ? srso_return_thunk+0x5/0x5f
kernel: ? range_tree_add_impl+0x785/0xde0 [zfs]
kernel: ? srso_return_thunk+0x5/0x5f
kernel: ? range_tree_remove_impl+0x876/0xe80 [zfs]
kernel: ? srso_return_thunk+0x5/0x5f
kernel: space_map_load_callback+0x7d/0x90 [zfs]
kernel: space_map_iterate+0x183/0x3e0 [zfs]
kernel: ? __pfx_space_map_load_callback+0x10/0x10 [zfs]
kernel: space_map_load_length+0x5e/0xe0 [zfs]
kernel: metaslab_load_impl+0xcc/0x590 [zfs]
kernel: ? srso_return_thunk+0x5/0x5f
kernel: ? zfs_btree_find+0x206/0x240 [zfs]
kernel: metaslab_load+0x81/0xd0 [zfs]
kernel: vdev_trim_calculate_progress+0x167/0x320 [zfs]
kernel: ? zap_lookup+0xe8/0x110 [zfs]
kernel: vdev_trim_load+0x24/0x170 [zfs]
kernel: vdev_trim_restart+0x19c/0x250 [zfs]
kernel: vdev_trim_restart+0x4a/0x250 [zfs]
kernel: ? srso_return_thunk+0x5/0x5f
kernel: ? spa_import_progress_set_notes+0x5b/0x80 [zfs]
kernel: vdev_trim_restart+0x4a/0x250 [zfs]
kernel: spa_load_impl.constprop.0+0x765/0x860 [zfs]
kernel: spa_load+0x76/0x130 [zfs]
kernel: spa_load_best+0x54/0x2d0 [zfs]
kernel: spa_import+0x1eb/0x690 [zfs]
kernel: zfs_ioc_pool_import+0x140/0x160 [zfs]
kernel: zfsdev_ioctl_common+0x63d/0x760 [zfs]
kernel: ? srso_return_thunk+0x5/0x5f
kernel: ? check_heap_object+0x33/0x150
kernel: ? srso_return_thunk+0x5/0x5f
kernel: zfsdev_ioctl+0x53/0xe0 [zfs]
kernel: __x64_sys_ioctl+0x8a/0xc0
kernel: do_syscall_64+0x5f/0xe0
kernel: ? srso_return_thunk+0x5/0x5f
kernel: ? mm_account_fault+0x6c/0x100
kernel: ? srso_return_thunk+0x5/0x5f
kernel: ? handle_mm_fault+0x138/0x270
kernel: ? srso_return_thunk+0x5/0x5f
kernel: ? do_user_addr_fault+0x35d/0x620
kernel: ? srso_return_thunk+0x5/0x5f
kernel: ? exc_page_fault+0x61/0x150
kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
kernel: RIP: 0033:0x7f6efb904c3b
kernel: Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ad 51 0f 00 f7 d8 64 89 01 48
kernel: RSP: 002b:00007ffc12bf8558 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
kernel: RAX: ffffffffffffffda RBX: 0000560940257dc0 RCX: 00007f6efb904c3b
kernel: RDX: 00007ffc12bf8ec0 RSI: 0000000000005a02 RDI: 0000000000000003
kernel: RBP: 00007ffc12bfc4b0 R08: 00005609402db510 R09: 0000000000000001
kernel: R10: 0000000000000fff R11: 0000000000000246 R12: 00007ffc12bf86c0
kernel: R13: 000056094024fbb0 R14: 00007ffc12bf8ec0 R15: 00005609402566c0
kernel: </TASK>
Pool layout (read-only import)
pool: tank
state: ONLINE
scan: scrub repaired 0B in 12:08:48 with 0 errors on Wed Apr 8 12:26:11 2026
remove: Removal of vdev 1 copied 2.87T in 6h13m, completed on Sat Jul 13 15:40:25 2024
12.7M memory used for removed device mappings
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-ST12000VN0008-2PH103_ZTN00BAZ ONLINE 0 0 0
ata-ST12000VN0008-2PH103_ZS800DQF ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
ata-ST16000NM000J-2TW103_ZR5CMS5Y ONLINE 0 0 0
ata-ST16000NM000J-2TW103_ZR5D66NJ ONLINE 0 0 0
logs
mirror-3 ONLINE 0 0 0
nvme-Samsung_SSD_970_EVO_Plus_250GB_S4EUNG0MC06749Y-part1 ONLINE 0 0 0
nvme-Samsung_SSD_970_EVO_Plus_250GB_S4EUNG0MC07044W-part1 ONLINE 0 0 0
cache
nvme-Samsung_SSD_970_EVO_Plus_250GB_S4EUNG0MC06749Y-part2 ONLINE 0 0 0
nvme-Samsung_SSD_970_EVO_Plus_250GB_S4EUNG0MC07044W-part2 ONLINE 0 0 0
System information
Describe the problem you're observing
System hangs when importing pool
Describe how to reproduce the problem
Unknown, machine seems to have crashed before this happened. log appruptly ends with a new "boot" line. In this boot I see a message about corrupt system.journal because of unclean shutdown and then when the zfs-import.service starts I see the stack trace posted below the first time.
I can import the pool in read-only mode just fine but so far I did not manage to recover the pool. SMART reports all good on the drives. No the nodes does not have ECC memory.
As the pool is rather big (for me) I would really like to recover it and not drop down to the backup from yesterday.
Include any warning/errors/backtraces from the system logs
Pool layout (read-only import)