[BACK]Return to porting_zfs.mdwn CVS log [TXT] [DIR] Up to [NetBSD Developer Wiki] / wikisrc / users / haad

Diff for /wikisrc/users/haad/Attic/porting_zfs.mdwn between versions 1.8 and 1.11

version 1.8, 2009/11/12 00:08:15 version 1.11, 2010/01/03 01:33:44
Line 2 Line 2
     
 NetBSD zfs port is work in progress and can easily panic your system.  NetBSD zfs port is work in progress and can easily panic your system.
   
 **ZFS currently works ony on i386!!**  **ZFS currently works ony on i386 and amd64!!**
   
 ---  ---
 # 2. Using NetBSD ZFS port   # 2. Using NetBSD ZFS port 
Line 56  After creating ZVOLS and filesystem they Line 56  After creating ZVOLS and filesystem they
   
 ### amd64  ### amd64
   
 amd64 related panic was fixed in version 1.1 of sys/arch/amd64/include/Makefile.inc by adding -mno-red-zone flag to amd64 modules build flags.  
   
 ### i386   ### i386 
   
 ### Both   ### Both 
 * vnode reclaiming deadlocks   * 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   * 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.    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.
   
   * kmem_cache_alloc/ aka pool_cache_get panicsdue to KM_NOSLEEP flag
    There are some problems in then NEtBSD UVM subsytem when KM_NOSLEEP allocation can fail even if system has enough memory to use. I talked with ad@ about it and he said that there is one problem in uvm where some lock is held, KM_NOSLEEP allocation will fail.
   
 ## Functional bugs   ## Functional bugs 
 * Snapshots  * Snapshots
 * Permissions  * Permissions
Removed from v.1.8  
changed lines
  Added in v.1.11

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb