version 1.9, 2009/12/23 23:37:21
|
version 1.10, 2009/12/24 00:16:22
|
Line 60 After creating ZVOLS and filesystem they
|
Line 60 After creating ZVOLS and filesystem they
|
|
|
### 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. |