Emmanuel Dreyfus <m...@netbsd.org> wrote: > db{0}> show vnode c5a24b08 > OBJECT 0xc5a24b08: locked=0, pgops=0xc0b185a8, npages=1720, refs=16 > > VNODE flags 0x4030<MPSAFE,LOCKSWORK,ONWORKLST> > mp 0xc4a14000 numoutput 0 size 0x6f0000 writesize 0x6f0000 > data 0xc5a25d74 writecount 0 holdcnt 2 > tag VT_UFS(1) type VREG(1) mount 0xc4a14000 typedata 0xc4fe5480 > v_lock 0xc5a24bac
While many threads are waiting, another nfsd thread holds the lock with this backtrace: turnstile_block rw_vector_enter wapbl_begin ffs_write VOP_WRITE nfsrv_write nfssvc_nfsd sys_nfssvc syscall I understand it is waiting for another process to complete I/O before passing the entering rwlock in wapbl_begin I have a first-class suspect with this other nfsd thread which is engaged in I/O: sleepq_block wdc_exec_command wd_flushcache wdioctl bdev_ioctl spec_ioctl VOP_IOCTL rf_sync_component_caches raidioctl bdev_ioctl spec_ioctl VOP_IOCTL wapbl_cache_sync Is it a nasty interraction between RAIDframe, NFS and WAPBL? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org