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

[Pawel Jakub Dawidek]

On Tue, Sep 25, 2012 at 12:08:40PM +0300, Konstantin Belousov wrote:
> On Tue, Sep 25, 2012 at 12:46:07AM +0200, Baptiste Daroussin wrote:
> > Hi,
> > 
> > I have the exact same problem making: tinderbox and poudriere highly
> > unusable.
> >
> > This is really problematic because pointyhat also rely on nullfs and
> > zfs, which means we can't upgrade the building nodes if we need to for
> > example.
> >
> > regards, Bapt
> 
> This is zfs bug. Filesystems shall not call getnewvnode() while holding
> internal locks. At least not the locks which are needed during reclaim.
> Nullfs changes amplified the probability of the problematic situation,
> since now nullfs vnodes are indeed cached instead of being recreated
> on each access, so the overall count of used vnodes could be twice as
> high.
> 
> You might try to increase the kern.maxvnodes to reduce the probability of
> the recursive calls into vnlnru() from getnewvnode(). But for real, bug
> needs to be fixed in zfs.

With all FreeBSD's VFS constraints, it is really hard to breath,
especially within file system that was not designed with our VFS
complexity in mind.

For example it would be nice of VFS to not reclaim vnodes from
getnewvnode() and leave this task entirely to the vnlru process.
It is pretty obvious layering violation to me - file system code needs
new vnode, it calls VFS routine to allocate one, which then calls file
system again to reclaim one of its vnodes.

It would also be nice to handle EAGAIN from VOP_RECLAIM(). Currently we
panic on error. This would be useful to return if some of the locks
cannot be acquired immediately. ZFS reclaim already discovers potential
deadlocks and defer some reclamation portion to separate thread.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://tupytaj.pl
-------------- 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/20120929/70388f79/attachment.pgp