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

version 1.11, 2010/01/03 01:33:44 version 1.12, 2012/04/06 11:24:12
Line 7  NetBSD zfs port is work in progress and  Line 7  NetBSD zfs port is work in progress and 
 ---  ---
 # 2. Using NetBSD ZFS port   # 2. Using NetBSD ZFS port 
   
 ## Instalation   ## Installation 
   
 Use any -current build from i386 or amd64 architecture. All tools and modules should be built by default, now. There are 2 modules used for ZFS solaris.kmod and zfs.kmod. Solaris module provides solaris like interfaces to zfs on NetBSD. The second module is zfs and provides zfs file system functions.  Use any -current build from i386 or amd64 architecture. All tools and modules should be built by default, now. There are 2 modules used for ZFS solaris.kmod and zfs.kmod. Solaris module provides solaris like interfaces to zfs on NetBSD. The second module is zfs and provides zfs file system functions.
   
Line 29  where type is: Line 29  where type is:
 * raidz2  * raidz2
 * default is normal linear allocation  * default is normal linear allocation
   
 device is blod device on netbsd /dev/sd0a for example.  device is blod device on NetBSD /dev/sd0a for example.
   
     zpool create tank mirror /dev/sd0a /dev/sd1a  creates mirrored zpool between 2 disk partitions.      zpool create tank mirror /dev/sd0a /dev/sd1a  creates mirrored zpool between 2 disk partitions.
   
Line 70  http://nxr.netbsd.org/xref/src/external/ Line 70  http://nxr.netbsd.org/xref/src/external/
   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  * 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.   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

Removed from v.1.11  
changed lines
  Added in v.1.12


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