When I use ztest or zdb from the same bits I get a dangling dufs error:
mix:pts/1$ ztest -VVVV
5 vdevs, 7 datasets, 23 threads, 300 seconds...
capacity operations bandwidth ---- errors ----
description used avail read write read write read write cksum
ztest 80.0K 238M 0 53 0 72.5K 0 0 0
mirror 80.0K 238M 0 53 0 72.5K 0 0 0
raidz 0 53 0 72.5K 0 0 0
/tmp/ztest.0a 0 560 0 1.44M 0 0 0
/tmp/ztest.1a 0 560 0 1.44M 0 0 0
/tmp/ztest.2a 0 566 0 1.44M 0 0 0
/tmp/ztest.3a 0 566 0 1.44M 0 0 0
raidz 0 53 0 72.5K 0 0 0
/tmp/ztest.4a 0 560 0 1.44M 0 0 0
/tmp/ztest.5a 0 560 0 1.44M 0 0 0
/tmp/ztest.6a 0 566 0 1.44M 0 0 0
/tmp/ztest.7a 0 566 0 1.44M 0 0 0
error: dangling dbufs (dn=102665ab0, dbuf=10266bd20)
zsh: IOT instruction (core dumped) ztest -VVVV
It is always the same dn and dbuf values when using ztest.
The stack trace from ztest is:
Loading modules: [ libumem.so.1 libzpool.so.1 libnvpair.so.1 libc.so.1
libavl.so.1 ld.so.1 ]
> $c
libc.so.1`_lwp_kill+8(6, 0, 100115278, ffffffffffffffff,
ffffffff7ebe8000, 0)
libc.so.1`abort+0x10c(1, 1d0, 8400, 0, 19f370, 0)
libzpool.so.1`panic+0x1c(ffffffff7f18bb30, 102665ab0, 10266bd20, 1, 3590,
102665e30)
libzpool.so.1`dnode_evict_dbufs+0x1e8(102665ab0, 10266bd78, 186, 0,
ffffffff7f29e000, 102665e20)
libzpool.so.1`dmu_objset_evict_dbufs+0xf4(ffffffff7ffff040, 0,
102661bc0, 162490, 10266ba00, 102661dc0)
libzpool.so.1`dmu_objset_evict+0x16c(0, 102661bc0, ffffffff7ebf3180,
162318, 4,
ffffffff7f29e000)
libzpool.so.1`dsl_pool_close+0x48(1024afa40, 10244b488, ffffffff7ebf3180,
10244b484, ffffffff7f502000, 102661be8)
libzpool.so.1`spa_unload+0x6c(10244b440, 6, 149278, 4, ffffffff7f29e000, 1)
libzpool.so.1`spa_evict_all+0xcc(100115e20, 10244b440, 8e3,
ffffffff7f29e000,
ffffffff7f191a08, ffffffff7f1919d8)
libzpool.so.1`spa_fini+0x20(5000, 6, 7, ffffffff7f29e000, 14322c, 102483500)
ztest_init+0x128(100113900, 100000, 0, 10000f000, 10000f, 102425e20)
main+0x234(1, 1, 100000, 1, 100113000, 100000)
_start+0x17c(0, 0, 0, 0, 0, 0)
Which kind of hints I might have a problem in my code rather than a
hardware problem.
Now were is it.....
--
Darren J Moffat
