ericdaltman
commented
6 years ago Not really sure what will help here so I'll add what I can think of. First of all, not using dedup or any such silliness.
Some messages from dbgmsg (many of which repeat heavily):
1532140180 dnode.c:1314:dnode_hold_impl(): error 2
1532140180 dnode.c:576:dnode_allocate(): os=ffffa04afee16800 obj=345529 txg=360 blocksize=131072 ibs=17 dn_slots=1
1532140179 dnode_sync.c:61:dnode_increase_indirection(): os=ffffa04afee16800 obj=344691, increase to 2
1532140188 dbuf.c:2269:dbuf_findbp(): error 2These appear once starting a zfs recv:
1532140545 dsl_prop.c:147:dsl_prop_get_dd(): error 2
1532140545 zap_micro.c:628:mzap_upgrade(): upgrading obj=1544 with 7 chunks
1532140545 zap_micro.c:640:mzap_upgrade(): adding org.zfsonlinux:userobj_accounting=0
1532140545 zap_leaf.c:441:zap_leaf_lookup(): error 2
1532140545 zap_micro.c:640:mzap_upgrade(): adding com.delphix:resume_fromguid=3794124285519673276
1532140545 zap_leaf.c:441:zap_leaf_lookup(): error 2
1532140545 zap_micro.c:640:mzap_upgrade(): adding com.delphix:resume_toguid=2494501697666804117
1532140545 dbuf.c:2269:dbuf_findbp(): error 2
1532140545 zap_leaf.c:441:zap_leaf_lookup(): error 2
1532140545 spa_history.c:317:spa_history_log_sync(): txg 425 receive REDACTED/REDACTED/%recv (id 1544)
1532140545 zap.c:766:fzap_checksize(): error 22
rincebrain
GregorKopka
stale[bot]
Quoor8ee
behlendorf
System information
Describe the problem you're observing
Receiving a zfs stream randomly leads to a kernel panic and forced reboot. This has happened with the same pool (with same JBOD chassis) with a totally different head unit (with the same installed software). The pool has been destroyed and recreated with no success in the process. This same head unit with a different pool attached (and receiving from a different pool's "zfs send") has succeeded. Two totally different types of HBAs have been tried as well. The sending machine is unaffected. No networking issues have been detected. vmcore-dump included below.
Describe how to reproduce the problem
Set up a "zfs recv" and wait. Sometimes we have a successful process and other attempts, even on the same datasets, leads to a kernel panic.
Include any warning/errors/backtraces from the system logs