Date: Tue, 24 May 2016 00:17:48 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 209158] node / npm triggering zfs rename deadlock Message-ID: <bug-209158-3630-9wR0PtqZEE@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-209158-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-209158-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209158 Rick Macklem <rmacklem@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmacklem@FreeBSD.org --- Comment #2 from Rick Macklem <rmacklem@FreeBSD.org> --- If it was possible, it might be useful to test with sysctl debug.vfscache=3D0 Why? Well there was a similar recent occurrence on Freefall, but where the vnode lock was on NFS. The similarity is that several of the threads that were waiting for the vnode lock were: cache_lookup()->vget()->_vn_lock()-> and r285632 changed cache_lookup() from using VI_LOCK() to vhold() before the vget() call. I am wondering if this change somehow broke the code. Anyhow, disabling name caching would avoid doing the code in cache_lookup(). Disabling name caching will have a performance hit, but it would be nice to see if this avoids the deadlock? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209158-3630-9wR0PtqZEE>