Thanks for the insight, it does appear that in all instances of this problem there is always one thread stuck on zfs_znode_alloc. Unfortunately its always a different application (e.g., perl, sh, postgres). I will post more information in the bug.
On Sat, Mar 2, 2019 at 12:48 PM Andriy Gapon <a...@freebsd.org> wrote: > On 01/03/2019 17:00, Nick Rogers wrote: > > 36704 101146 perl - mi_switch+0xe1 > > sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_xlock_hard+0x19c > VOP_LOCK1_APV+0x7e > > _vn_lock+0x40 zfs_znode_alloc+0x434 zfs_mknode+0xa9d > > zfs_freebsd_create+0x512 VOP_CREATE_APV+0x78 vn_open_cred+0x2c9 > > kern_openat+0x20c amd64_syscall+0x369 fast_syscall_common+0x101 > > I suspect that this thread is a root cause of the problem. > In this place, the vnode should be freshly created and not visible to > anything > but the current thread. So, vn_lock() should always immediately succeed. > I > cannot understand how the vnode lock could be held by another thread. > > -- > Andriy Gapon > _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
