Bug #764
closed
panic in zfs:dbuf_sync_list
0%
Description
Workload is Robocopy on Windows connected to a CIFS share,
and writing lots of files onto ZFS. Get panics like:
panic[cpu2]/thread=ffffff0046ac6c60:
BAD TRAP: type=e (#pf Page fault) rp=ffffff0046ac67c0 addr=108 occurred in modul
e "zfs" due to a NULL pointer dereference
ffffff0046ac68e0 zfs:dbuf_sync_list+46 ()
ffffff0046ac6950 zfs:dnode_sync+377 ()
ffffff0046ac69a0 zfs:dmu_objset_sync_dnodes+80 ()
ffffff0046ac6a30 zfs:dmu_objset_sync+1da ()
ffffff0046ac6a70 zfs:dsl_dataset_sync+5d ()
ffffff0046ac6af0 zfs:dsl_pool_sync+c0 ()
ffffff0046ac6ba0 zfs:spa_sync+37b ()
ffffff0046ac6c40 zfs:txg_sync_thread+247 ()
ffffff0046ac6c50 unix:thread_start+8 ()
Updated by Gordon Ross over 12 years ago
It's been suggested that this bug may be related:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6985729
(mkfile can trigger various dmu panics when file has spill block)
The common factor is replacing ACLs that are large enough
so the are stored in ZFS "spill" blocks.
Updated by Gordon Ross over 12 years ago
Hypothesis about what's going on here.
At some time in the past, something, i.e. dnode_reallocate()
calls one of:
dbuf_rm_spill(dn, tx);
These will do:
dbuf_rm_spill(dnode_t *dn, dmu_tx_t *tx)
dbuf_free_range(dn, DMU_SPILL_BLKID, DMU_SPILL_BLKID, tx)
dbuf_undirty(db, tx)
Currently dbuf_undirty can leave a spill block in dn_dirty_records[],
(it having been put there previously by dbuf_dirty) and free it.
Sometime later, dbuf_sync_list trips over this reference to free'd
(and typically reused) memory.
Also, dbuf_undirty can call dnode_clear_range with a bogus
block ID. It needs to test for DMU_SPILL_BLKID, similar to
how dnode_clear_range is called in dbuf_dirty().
Updated by Gordon Ross over 12 years ago
- Status changed from New to Resolved
Fix pushed to illumos-gate:
changeset: 13298:c234f438c0d3
tag: tip
user: Gordon Ross <gwr@nexenta.com>
date: Tue Mar 08 16:39:19 2011 -0500
description:
764 panic in zfs:dbuf_sync_list
Reviewed by: George Wilson <gwilson@zfsmail.com>
Reviewed by: Mark.Maybe@oracle.com
Reviewed by: Albert Lee <trisk@nexenta.com
Approved by: Garrett D'Amore <garrett@nexenta.com>