Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jan 2014 13:46:35 +0200
From:      Andriy Gapon <avg@FreeBSD.org>
To:        krichy@tvnetwork.hu
Cc:        freebsd-fs@FreeBSD.org
Subject:   Re: kern/184677 / ZFS snapshot handling deadlocks
Message-ID:  <52D5239B.6000203@FreeBSD.org>
In-Reply-To: <alpine.DEB.2.10.1312250614001.2785@krichy.tvnetwork.hu>
References:  <alpine.DEB.2.10.1312161647410.11599@krichy.tvnetwork.hu> <alpine.DEB.2.10.1312171326520.7714@krichy.tvnetwork.hu> <alpine.DEB.2.10.1312191629370.4344@krichy.tvnetwork.hu> <20131220134405.GE1658@garage.freebsd.pl> <alpine.DEB.2.10.1312231750030.31822@krichy.tvnetwork.hu> <alpine.DEB.2.10.1312240706470.8128@krichy.tvnetwork.hu> <alpine.DEB.2.10.1312242126250.19813@krichy.tvnetwork.hu> <alpine.DEB.2.10.1312242133240.20268@krichy.tvnetwork.hu> <alpine.DEB.2.10.1312250614001.2785@krichy.tvnetwork.hu>

next in thread | previous in thread | raw e-mail | index | archive | help
on 25/12/2013 07:22 krichy@tvnetwork.hu said the following:
> I've made a new patch again, which fixes most of my earlier issues. Mainly, I've
> enabled shared vnode locks for GFS vnodes - is it acceptable? And that way,
> deadlock cases reduced much, and also the patch is more clear (at least to me).
> One thing still remains, the spa_namespace_lock race I mentioned before, I dont
> know how to handle that.
> 
> Waiting for comments on this.

Richard,

first of all, apologies for the delay with a reply and for not having any
comment on the essence of your patch...

I do have the following meta-comment.

- working with FreeBSD VFS is hard
- porting code that was written for a very different VFS model to FreeBSD VFS is
even harder
- doing the same for the code that plays various tricks, like .zfs support code
does, is harder again
- reviewing somebody else's changes to that kind of code is harder still than
making such changes

This is quite an unfortunate situation.  I am not much surprised by the lack of
followups to your analysis and patches.
I am saying this as someone who spent some time analyzing and trying to fix the
.zfs code and ZFS<->VFS interaction in general.  See e.g.
http://thread.gmane.org/gmane.os.freebsd.devel.file-systems/18924/focus=19056

My opinion is that .zfs code breaks several fundamental FreeBSD VFS contracts.
The most glaring violation is that VOP_INACTIVE makes a vnode invalid.
I think that trying to fix .zfs code by patching individual problems here and
there is an uphill battle.  I think that the same also applies to ZFS ZPL code
but in a less obvious way.
The code in many cases just pretends to play by VFS rules by satisfying most
obvious assertions, but it does not really try to obey VFS contracts.  For
example, almost all locks in znode are mostly redundant given VFS vnode locking.
 But in some cases they are not sufficient precisely because VFS expects its
locking to be used rather than ZFS internal locking.  The most obvious example
is interaction of VOP_RENAME with other VOPs.

In any case, thanks for your work!  I am trying to find some time to review it.

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52D5239B.6000203>