--- wikisrc/users/haad/Attic/porting_zfs.mdwn	2009/12/23 23:37:21	1.9
+++ wikisrc/users/haad/Attic/porting_zfs.mdwn	2009/12/24 00:16:22	1.10
@@ -60,21 +60,11 @@ After creating ZVOLS and filesystem they
 
 ### Both 
 * vnode reclaiming deadlocks 
- 
- This can be fixed by deferring call to zfs_zinactive in zfs_reclaim to another system thread if lock is held.
- But it causes deadlock and we need to investigate if it is caused by this change or by another problem.
-			
- Deadlock backtrace is this
-			
- VOP_WRITE->zfs_netbsd_write->zfs_write->dmu_tx_wait->txg_wait_open->cv_wait
- txq_quisce_thread->txg_thread_wait->cv_wait
- txg_sync_thread->spa_sync->dsl_pool_sync->zio_wait->cv_wait
-			
- FreeBSD approach should be investigated why they are doing this differently and why it works for them. They 
- call zfs_zinactive from zfs_freebsd_inactive which is null op for NetBSD.
-			
- zfs umount panic is caused by using FreeBSD approach in zfs_reclaim.
 
+Current code is quite a hack but it works until I will find some time to rework vnode reclaiming on NetBSD.
+
+http://nxr.netbsd.org/xref/src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c#4254
+ 
 * vnode fsync bug 
   
   I think that we are hitting this bug, too. I have some patches in the tree which fixes deadlod in vnode reclaim but after that I'm getting another deadlock in VOP_FSYNC.