Return to porting_zfs.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc / users / haad

web commit by haad

    1: # 1. Status of NetBSD zfs port
    2:  
    3: NetBSD zfs port is work in progress and can easily panic your system.
    4: 
    5: **ZFS currently works ony on i386!!**
    6: 
    7: ---
    8: # 2. Using NetBSD ZFS port 
    9: 
   10: ## Instalation 
   11: 
   12: 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.
   13: 
   14: ## Configuration
   15: 
   16: User need to
   17: 
   18:  modload solaris
   19:  modload zfs
   20: 
   21: After loading modules user can create zpool(zfs version of volume manager) and manage zfs file systems on it. 
   22: 
   23: zpool create {name} {type} {device} 
   24: 
   25: type:
   26:  * mirror
   27:  * raidz
   28:  * raidz2
   29:  * default is normal linear allocation
   30: 
   31: device is blod device on netbsd /dev/sd0a for example.
   32: 
   33: zpool create tank mirror /dev/sd0a /dev/sd1a  creates mirrored zpool between 2 disk partitions.
   34: 
   35: 
   36: ## Administration
   37: 
   38: ---
   39: # 3. Known Bugs
   40: 
   41: ## Show stoppers 
   42: 
   43: ### amd64
   44: * amd64 zio_root crash
   45: Investigation 
   46: vdev_label_read_config -> zio_root calls zio_wait on a zio_root zio_t. Later zio_execute tries to generate 			
   47: checksum on zio->zio_data which is NULL for a zio_root. Is this ressurrection of andys zio_null problem ? 
   48: because zio_root is basicaly zio_null.
   49: 		
   50:  Solution
   51:  What is difference between i386 and amd64 version why it is working on i386 and not on a amd64 that can be
   52:  solution.
   53: ### i386 
   54: 
   55: ### Both 
   56: * vnode reclaiming deadlocks 
   57:  
   58:  This can be fixed by deferring call to zfs_zinactive in zfs_reclaim to another system thread if lock is held.
   59:  But it causes deadlock and we need to investigate if it is caused by this change or by another problem.
   60: 			
   61:  Deadlock backtrace is this
   62: 			
   63:  VOP_WRITE->zfs_netbsd_write->zfs_write->dmu_tx_wait->txg_wait_open->cv_wait
   64:  txq_quisce_thread->txg_thread_wait->cv_wait
   65:  txg_sync_thread->spa_sync->dsl_pool_sync->zio_wait->cv_wait
   66: 			
   67:  FreeBSD approach should be investigated why they are doing this differently and why it works for them. They 
   68:  call zfs_zinactive from zfs_freebsd_inactive which is null op for NetBSD.
   69: 			
   70:  zfs umount panic is caused by using FreeBSD approach in zfs_reclaim.
   71: 
   72: 
   73: ## Functional bugs 
   74: * Snapshots
   75: * Permissions
   76: * Old code, we should update NetBSD zfs port to new code