From owner-svn-src-all@freebsd.org Thu Aug 11 23:25:16 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01D38BB66C5; Thu, 11 Aug 2016 23:25:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E2D931D5C; Thu, 11 Aug 2016 23:25:15 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 7CD55171C; Thu, 11 Aug 2016 23:25:15 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 11 Aug 2016 23:25:14 +0000 From: Glen Barber To: Slawa Olhovchenkov Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-11@freebsd.org, Andriy Gapon Subject: Re: svn commit: r303970 - in stable/11/sys/cddl: compat/opensolaris/sys contrib/opensolaris/uts/common/fs/zfs contrib/opensolaris/uts/common/fs/zfs/sys Message-ID: <20160811232514.GI51184@FreeBSD.org> References: <201608112048.u7BKm4OH076291@repo.freebsd.org> <20160811223331.GF22212@zxy.spb.ru> <20160811223637.GE51184@FreeBSD.org> <20160811225202.GI8192@zxy.spb.ru> <20160811225723.GG51184@FreeBSD.org> <20160811230747.GJ8192@zxy.spb.ru> <20160811231317.GH51184@FreeBSD.org> <20160811232025.GG22212@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oxV4ZoPwBLqAyY+a" Content-Disposition: inline In-Reply-To: <20160811232025.GG22212@zxy.spb.ru> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 23:25:16 -0000 --oxV4ZoPwBLqAyY+a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 12, 2016 at 02:20:25AM +0300, Slawa Olhovchenkov wrote: > On Thu, Aug 11, 2016 at 11:13:17PM +0000, Glen Barber wrote: >=20 > > 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: > > >=20 > > > > 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: > > > > >=20 > > > > > > On Fri, Aug 12, 2016 at 01:33:31AM +0300, Slawa Olhovchenkov wr= ote: > > > > > > > On Thu, Aug 11, 2016 at 08:48:04PM +0000, Andriy Gapon wrote: > > > > > > >=20 > > > > > > > > Author: avg > > > > > > > > Date: Thu Aug 11 20:48:03 2016 > > > > > > > > New Revision: 303970 > > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/303970 > > > > > > > >=20 > > > > > > > > Log: > > > > > > > > MFC r303763,303791,303869: zfs: honour and make use of vf= s vnode locking protocol > > > > > > > > =20 > > > > > > > > ZFS POSIX Layer is originally written for Solaris VFS whi= ch is very > > > > > > > > different from FreeBSD VFS. Most importantly many things= that FreeBSD VFS > > > > > > > > manages on behalf of all filesystems are implemented in Z= PL in a different > > > > > > > > way. > > > > > > > > Thus, ZPL contains code that is redundant on FreeBSD or d= uplicates VFS > > > > > > > > functionality or, in the worst cases, badly interacts / i= nterferes > > > > > > > > with VFS. > > > > > > > > =20 > > > > > > > > The most prominent problem is a deadlock caused by the lo= ck order reversal > > > > > > > > of vnode locks that may happen with concurrent zfs_rename= () and lookup(). > > > > > > > > The deadlock is a result of zfs_rename() not observing th= e vnode locking > > > > > > > > contract expected by VFS. > > > > > > > > =20 > > > > > > > > This commit removes all ZPL internal locking that protect= s parent-child > > > > > > > > relationships of filesystem nodes. These relationships a= re protected > > > > > > > > by vnode locks and the code is changed to take advantage = of that fact > > > > > > > > and to properly interact with VFS. > > > > > > > > =20 > > > > > > > > Removal of the internal locking allowed all ZPL dmu_tx_as= sign calls to > > > > > > > > use TXG_WAIT mode. > > > > > > > > =20 > > > > > > > > Another victim, disputable perhaps, is ZFS support for fi= lesystems with > > > > > > > > mixed case sensitivity. That support is not provided by = the OS anyway, > > > > > > > > so in ZFS it was a buch of dead code. > > > > > > > > =20 > > > > > > > > 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 > > > > > > >=20 > > > > > > > MFC to 10.x/9.x planed? > > > > > > >=20 > > > > > >=20 > > > > > > As I understand it, this does not affect stable/10. > > > > >=20 > > > > > Sure? > > > > > I think ZFS/VFS layers don't change between 9.x and 11.x > > > > >=20 > > > >=20 > > > > No, but as I understand it, a commit to head tickled this bug. avg= @ can > > > > correct me if I am wrong. > > >=20 > > > 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. > > >=20 > >=20 > > I agree with you. I am just unsure if this particular bug affects 10.x > > and 9.x. >=20 > What purpose to limit (?) MFC to 9.x/10.x to bug fix only? > Or I am missing some in ypu point? >=20 I think you are missing what I mean. I am not sure if the change that introduced this issue made it to 10.x or 9.x. But, I know it is a long lasting issue that was around for a while, but the change in current that triggered this specific issue does not affect 10.x or 9.x. Glen --oxV4ZoPwBLqAyY+a Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXrQlaAAoJEAMUWKVHj+KTOvwQAIY1IkJ4RWjZGjoXMvH3wZSD fKsgenoQGWpxdS9yl3Ctx0LUogWuK3XIxuF4p/SgYU7GBgHMNvNWtOtPwe6Tgbug gJQMB9uS+A7jXsVu/v7EpRtBN3haupFwD1OZXZRQIQm+6paxC4esSyHaZvGhu7vA ZftY24e2pSbwxtl6pVH4AyegEQQb6AFyKkUibAJjkr5LzzdXo8RFDDCf5hEJ3PWG SKljO2rdZrtcIEVK2is4njafg0yjnGRV7LJzfHJrXKg61M8zDOEjGtP8wd4gzuzl tgyp9naFr5+xEhfUhaRkuVq9NzO44igB7bKZ5eOpPTVVPVlPbn38y98UR+25W8UM 9Stb4jevNMaw63T+7zOYe02Ul0I0CYjysfzRCZqA5RiXqslaCjS47O1oo3GA0tjT sgku70mLPc1kGN7qHmYT/jnrC6GNsXsJDbVQ2ckigcw8gGaTO+icisXY8Op4tKBN 8agz5B5HqzB9jfAFv1FoLdEH+1N2fxicvCfd+YC2ugVvEAFaCQhzcA/eBjYG5nlk pDzyTRiaE6jAHivaTA+eBfA1IHy4Yj6UKi0SCow8PJ/JlHxixySaicYFBPgw0Oym j3gHWuAxZP6gkX1IxzUI2XjeuyHDJTpM5zgwJJVlrDpqIXRFIcQfXKVLgH1mMvN3 wmgAoxUvi+74syUL3UU9 =VTBY -----END PGP SIGNATURE----- --oxV4ZoPwBLqAyY+a--