System information
| Type |
Version/Name |
| Distribution Name |
Truenas Scale |
| Distribution Version |
26.0 beta 2 |
| Kernel Version |
6.18 LTS |
| Architecture |
amd64 |
| OpenZFS Version |
2.3.2 |
Describe the problem you're observing
Environment:
Original: TrueNAS SCALE (OpenZFS ~2.2-2.3)
Tested also on: Debian 10 (Buster) stock ZFS 2.0.3, and Debian 13 (Trixie) Live with ZFS 2.3.2
Pool layout: 4-disk raidz1 + 2-disk mirrored log (SLOG) vdev + 1 L2ARC cache device
Background: Pool experienced an unclean shutdown, followed by a single drive failure/replacement and resilver. Post-resilver scrub found 4 permanent, contained data errors — two objects, one file, and one dataset object, all under Media/ix-apps/docker (a Docker/container runtime storage dataset — disposable app data, not primary content).
Symptom: Pool imports and mounts cleanly with zpool import -o readonly=on. Every read-write import attempt (-f, -m, -F, and all combinations, including with the two log devices physically removed) hangs indefinitely at the same point:
'Media' Claiming ZIL blocks
'Media' Syncing ZIL claims
No further dbgmsg output follows — process sits in D state indefinitely, unkillable.
Stack trace of the blocked import process:
[<0>] cv_wait_common+0xab/0x130 [spl]
[<0>] txg_wait_synced_flags+0xc9/0x130 [zfs]
[<0>] txg_wait_synced+0x10/0x40 [zfs]
[<0>] spa_load_impl.constprop.0+0x3c3/0x580 [zfs]
[<0>] spa_load+0x70/0x120 [zfs]
[<0>] spa_load_best+0x54/0x290 [zfs]
[<0>] spa_import+0x1f6/0x5e0 [zfs]
[<0>] zfs_ioc_pool_import+0x14a/0x160 [zfs]
Ruled out:
Middleware/lock contention (reproduced identically on bare Debian, no competing processes)
ZFS version mismatch (reproduced on 2.0.3, 2.2.x, and 2.3.2)
Physical log device hardware fault (identical hang persists with both log devices physically removed from the system, -m passed)
Question: Given ZIL claim/replay appears to be the specific blocking step, is there a way to skip ZIL claiming entirely, or a zdb-level manual approach to inspect/clear the specific pending transaction, given -F rollback doesn't resolve it?
Describe how to reproduce the problem
Include any warning/errors/backtraces from the system logs
System information
Describe the problem you're observing
Environment:
Original: TrueNAS SCALE (OpenZFS ~2.2-2.3)
Tested also on: Debian 10 (Buster) stock ZFS 2.0.3, and Debian 13 (Trixie) Live with ZFS 2.3.2
Pool layout: 4-disk raidz1 + 2-disk mirrored log (SLOG) vdev + 1 L2ARC cache device
Background: Pool experienced an unclean shutdown, followed by a single drive failure/replacement and resilver. Post-resilver scrub found 4 permanent, contained data errors — two objects, one file, and one dataset object, all under Media/ix-apps/docker (a Docker/container runtime storage dataset — disposable app data, not primary content).
Symptom: Pool imports and mounts cleanly with zpool import -o readonly=on. Every read-write import attempt (-f, -m, -F, and all combinations, including with the two log devices physically removed) hangs indefinitely at the same point:
'Media' Claiming ZIL blocks
'Media' Syncing ZIL claims
No further dbgmsg output follows — process sits in D state indefinitely, unkillable.
Stack trace of the blocked import process:
[<0>] cv_wait_common+0xab/0x130 [spl]
[<0>] txg_wait_synced_flags+0xc9/0x130 [zfs]
[<0>] txg_wait_synced+0x10/0x40 [zfs]
[<0>] spa_load_impl.constprop.0+0x3c3/0x580 [zfs]
[<0>] spa_load+0x70/0x120 [zfs]
[<0>] spa_load_best+0x54/0x290 [zfs]
[<0>] spa_import+0x1f6/0x5e0 [zfs]
[<0>] zfs_ioc_pool_import+0x14a/0x160 [zfs]
Ruled out:
Middleware/lock contention (reproduced identically on bare Debian, no competing processes)
ZFS version mismatch (reproduced on 2.0.3, 2.2.x, and 2.3.2)
Physical log device hardware fault (identical hang persists with both log devices physically removed from the system, -m passed)
Question: Given ZIL claim/replay appears to be the specific blocking step, is there a way to skip ZIL claiming entirely, or a zdb-level manual approach to inspect/clear the specific pending transaction, given -F rollback doesn't resolve it?
Describe how to reproduce the problem
Include any warning/errors/backtraces from the system logs