1: # 1. Status of NetBSD zfs port
2:
3: NetBSD zfs port is work in progress and can easily panic your system.
4: ---
5: # 2. Using NetBSD ZFS port
6:
7:
8: ## Instalation
9:
10: ## Configuration
11:
12: ## Administration
13:
14: ---
15: # 3. Known Bugs
16:
17: ## Show stoppers
18:
19: ### amd64
20: * amd64 zio_root crash
21: Investigation
22: vdev_label_read_config -> zio_root calls zio_wait on a zio_root zio_t. Later zio_execute tries to generate
23: checksum on zio->zio_data which is NULL for a zio_root. Is this ressurrection of andys zio_null problem ?
24: because zio_root is basicaly zio_null.
25:
26: Solution
27: What is difference between i386 and amd64 version why it is working on i386 and not on a amd64 that can be
28: solution.
29: ### i386
30:
31: ### Both
32: * vnode reclaiming deadlocks
33:
34: This can be fixed by deferring call to zfs_zinactive in zfs_reclaim to another system thread if lock is held.
35: But it causes deadlock and we need to investigate if it is caused by this change or by another problem.
36:
37: Deadlock backtrace is this
38:
39: VOP_WRITE->zfs_netbsd_write->zfs_write->dmu_tx_wait->txg_wait_open->cv_wait
40: txq_quisce_thread->txg_thread_wait->cv_wait
41: txg_sync_thread->spa_sync->dsl_pool_sync->zio_wait->cv_wait
42:
43: FreeBSD approach should be investigated why they are doing this differently and why it works for them. They
44: call zfs_zinactive from zfs_freebsd_inactive which is null op for NetBSD.
45:
46: zfs umount panic is caused by using FreeBSD approach in zfs_reclaim.
47:
48:
49: ## Functional bugs
50: * Snapshots
51: * Permissions
52: * Old code, we should update NetBSD zfs port to new code
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb