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 coul
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
Jorgen,
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.
Thanks,
George
On Sat, Aug 22, 2
Hello list;
So running the test environment, we can regularly trigger the following
VERIFY:
panic(cpu 0 caller 0xff7f8a065e08): "VERIFY3(" "0" " " "==" " "
"rt->rt_space" ") " "failed (" "0" " " "==" " " "14336"
")\n"@range_tree.c:153
I threw in some code to determine the allocator;
