svn commit: r303970 - in stable/11/sys/cddl: compat/opensolaris/sys contrib/opensolaris/uts/common/fs/zfs contrib/opensolaris/uts/common/fs/zfs/sys

[Slawa Olhovchenkov]

On Thu, Aug 11, 2016 at 11:13:17PM +0000, Glen Barber wrote:

> On Fri, Aug 12, 2016 at 02:07:47AM +0300, Slawa Olhovchenkov wrote:
> > On Thu, Aug 11, 2016 at 10:57:23PM +0000, Glen Barber wrote:
> > 
> > > On Fri, Aug 12, 2016 at 01:52:02AM +0300, Slawa Olhovchenkov wrote:
> > > > On Thu, Aug 11, 2016 at 10:36:37PM +0000, Glen Barber wrote:
> > > > 
> > > > > On Fri, Aug 12, 2016 at 01:33:31AM +0300, Slawa Olhovchenkov wrote:
> > > > > > On Thu, Aug 11, 2016 at 08:48:04PM +0000, Andriy Gapon wrote:
> > > > > > 
> > > > > > > Author: avg
> > > > > > > Date: Thu Aug 11 20:48:03 2016
> > > > > > > New Revision: 303970
> > > > > > > URL: https://svnweb.freebsd.org/changeset/base/303970
> > > > > > > 
> > > > > > > Log:
> > > > > > >   MFC r303763,303791,303869: zfs: honour and make use of vfs vnode locking protocol
> > > > > > >   
> > > > > > >   ZFS POSIX Layer is originally written for Solaris VFS which is very
> > > > > > >   different from FreeBSD VFS.  Most importantly many things that FreeBSD VFS
> > > > > > >   manages on behalf of all filesystems are implemented in ZPL in a different
> > > > > > >   way.
> > > > > > >   Thus, ZPL contains code that is redundant on FreeBSD or duplicates VFS
> > > > > > >   functionality or, in the worst cases, badly interacts / interferes
> > > > > > >   with VFS.
> > > > > > >   
> > > > > > >   The most prominent problem is a deadlock caused by the lock order reversal
> > > > > > >   of vnode locks that may happen with concurrent zfs_rename() and lookup().
> > > > > > >   The deadlock is a result of zfs_rename() not observing the vnode locking
> > > > > > >   contract expected by VFS.
> > > > > > >   
> > > > > > >   This commit removes all ZPL internal locking that protects parent-child
> > > > > > >   relationships of filesystem nodes.  These relationships are protected
> > > > > > >   by vnode locks and the code is changed to take advantage of that fact
> > > > > > >   and to properly interact with VFS.
> > > > > > >   
> > > > > > >   Removal of the internal locking allowed all ZPL dmu_tx_assign calls to
> > > > > > >   use TXG_WAIT mode.
> > > > > > >   
> > > > > > >   Another victim, disputable perhaps, is ZFS support for filesystems with
> > > > > > >   mixed case sensitivity.  That support is not provided by the OS anyway,
> > > > > > >   so in ZFS it was a buch of dead code.
> > > > > > >   
> > > > > > >   To do:
> > > > > > >   - replace ZFS_ENTER mechanism with VFS managed / visible mechanism
> > > > > > >   - replace zfs_zget with zfs_vget[f] as much as possible
> > > > > > >   - get rid of not really useful now zfs_freebsd_* adapters
> > > > > > >   - more cleanups of unneeded / unused code
> > > > > > >   - fix / replace .zfs support
> > > > > > 
> > > > > > MFC to 10.x/9.x planed?
> > > > > > 
> > > > > 
> > > > > As I understand it, this does not affect stable/10.
> > > > 
> > > > Sure?
> > > > I think ZFS/VFS layers don't change between 9.x and 11.x
> > > > 
> > > 
> > > No, but as I understand it, a commit to head tickled this bug.  avg@ can
> > > correct me if I am wrong.
> > 
> > May be I am wrong, I see messages about like issuses in 9.x/10.x.
> > As I understund this is more clear implementation.
> > Also, unification in 12.x/10.x take benefit for MFC other ZFS diffs.
> > 
> 
> I agree with you.  I am just unsure if this particular bug affects 10.x
> and 9.x.

What purpose to limit (?) MFC to 9.x/10.x to bug fix only?
Or I am missing some in ypu point?