Jorgen, Since you're unloading the pool, there should not be any new allocations or frees happening. This is actually prevented by the call to txg_sync_stop() from spa_unload(). Here it should perform the final txg_wait_synced() to clear out all the ms_freetrees and stop the sync thread.
You could add an ASSERT at the end of txg_stop_sync() to determine that the trees are actually empty. I would also look at callers of metaslab_free_dva() after the txg sync thread has been stopped. Let me know what you find out. Thanks, George On Thu, Aug 27, 2015 at 4:42 AM, Jorgen Lundman <lund...@lundman.net> wrote: > >> Can you provide some details about the stack trace when you hit this >> failure. All of the ms_freetrees should be empty by the time you can >> range_tree_destroy(). So to debug this we need to understand the calling >> stack to determine why that isn't happening. >> >> > The stack at the moment of the VERIFY0() triggered panic is: > > Aug 27 03:26:24 big-vm-mac kernel[0]: ZFS: rt->rt_space is !0 : space 6144 > from metaslab.c:1982 > Aug 27 03:26:24 big-vm-mac kernel[0]: zfs: 2103296 (512) > Aug 27 03:26:24 big-vm-mac kernel[0]: zfs: 2125824 (1024) > Aug 27 03:26:24 big-vm-mac kernel[0]: zfs: 2128896 (2560) > Aug 27 03:26:24 big-vm-mac kernel[0]: zfs: 2144256 (2048) > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: backtrace "range_tree_destroy" > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: 0xffffff88a06738e0 : > 0xffffff7fa4c0471e net.lundman.zfs : _range_tree_destroy + 0x6e > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: 0xffffff88a0673900 : > 0xffffff7fa4c00510 net.lundman.zfs : _metaslab_fini + 0x140 > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: 0xffffff88a0673940 : > 0xffffff7fa4c2b804 net.lundman.zfs : _vdev_metaslab_fini + 0x84 > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: 0xffffff88a0673970 : > 0xffffff7fa4c2b453 net.lundman.zfs : _vdev_free + 0x83 > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: 0xffffff88a06739a0 : > 0xffffff7fa4c2b425 net.lundman.zfs : _vdev_free + 0x55 > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: 0xffffff88a06739d0 : > 0xffffff7fa4c1121f net.lundman.zfs : _spa_unload + 0x11f > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: 0xffffff88a06739f0 : > 0xffffff7fa4c1363a net.lundman.zfs : _spa_export_common + 0x29a > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: 0xffffff88a0673a30 : > 0xffffff7fa4c13395 net.lundman.zfs : _spa_destroy + 0x25 > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: 0xffffff88a0673a50 : > 0xffffff7fa4c65b2e net.lundman.zfs : _zfs_ioc_pool_destroy + 0x1e > Aug 27 03:26:24 big-vm-mac kernel[0]: SPL: 0xffffff88a0673a70 : > 0xffffff7fa4c622fc net.lundman.zfs : _zfsdev_ioctl + 0x66c > > > > _______________________________________________ > developer mailing list > developer@open-zfs.org > http://lists.open-zfs.org/mailman/listinfo/developer >
_______________________________________________ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer