panic: _sx_xlock_hard: recursed on non-recursive sx zfsvfs->z_hold_mtx[i] @ ...cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1407

[Baptiste Daroussin]

On Wed, Oct 03, 2012 at 11:42:03AM +0300, Andriy Gapon wrote:
> on 30/09/2012 15:24 Konstantin Belousov said the following:
> > The postponing of the reclaim when vnode reserve goes low to the vnlru 
> > process does not solve anything, since you only change the recursion into 
> > the deadlock.
> > 
> > I discussed an approach for this issue with avg. Basic idea is presented in
> > the untested patch below. You can specify that some count of the free
> > vnodes must be present for some dynamic scope, started by 
> > getnewvnode_reserve() function. While staying inside the reserved pool,
> > getnewvnode() calls would not recurse into vnlru(). The scope is finished
> > with getnewvnode_drop_reserve().
> > 
> > The getnewvnode_reserve() shall be called while no locks are held.
> > 
> > What do you think ?
> 
> Here is a patch that makes use of the getnewvnode_reserve API in ZFS:
> http://people.freebsd.org/~avg/zfs-getnewvnode.diff
> 

I can confirm that this patch solve the situation for me, I have been heavily
stressing it on my buildbox during all the night using poudriere and everything
worked where previously failed quite fastly.

regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20121003/11151526/attachment.pgp