From owner-freebsd-fs@FreeBSD.ORG Sun Jul 21 16:19:09 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 14844C93; Sun, 21 Jul 2013 16:19:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id AB55F8C7; Sun, 21 Jul 2013 16:19:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6LGIsd7016045; Sun, 21 Jul 2013 19:18:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6LGIsd7016045 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6LGIsWw016044; Sun, 21 Jul 2013 19:18:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jul 2013 19:18:54 +0300 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Deadlock in nullfs/zfs somewhere Message-ID: <20130721161854.GC5991@kib.kiev.ua> References: <20130718112814.GA5991@kib.kiev.ua> <51E7F05A.5020609@FreeBSD.org> <20130718185215.GE5991@kib.kiev.ua> <51E91277.3070309@FreeBSD.org> <20130719103025.GJ5991@kib.kiev.ua> <51E95CDD.7030702@FreeBSD.org> <20130719184243.GM5991@kib.kiev.ua> <51E99477.1030308@FreeBSD.org> <20130721071124.GY5991@kib.kiev.ua> <51EBABAB.5040808@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4tkssvp36SW1tyIS" Content-Disposition: inline In-Reply-To: <51EBABAB.5040808@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 16:19:09 -0000 --4tkssvp36SW1tyIS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 21, 2013 at 12:36:43PM +0300, Andriy Gapon wrote: > on 21/07/2013 10:11 Konstantin Belousov said the following: > > On Fri, Jul 19, 2013 at 10:33:11PM +0300, Andriy Gapon wrote: > >> on 19/07/2013 21:42 Konstantin Belousov said the following: > >>> Then, you cannot use VFS suspension. Or, in other words, you are > >>> directed to abuse the VFS interface. I assure you that any changes to > >>> the interface would not take into account such abuse and probably bre= ak > >>> your hack. > >>=20 > >> So what would be your recommendation about this problem? Should we add > >> another flavor of VFS suspension? The one that would mean "all external > >> accesses to this fs must be put on hold", but would not imply "this fs= is > >> frozen". > >=20 > > Suspension is very complicated as it is. Adding another flavour would= =20 > > multiply the current mess^H^H^H^H collection of subtleties. IMO, the be= st > > route is to use the KPI properly, i.e. adding the vn_start_write() brac= es > > around the top-level entries in the mutating code paths. > >=20 >=20 > So how will this help with doing a rollback in the thread that does the f= ollowing? >=20 > vfs_write_suspend > zfs rollback > vfs_write_resume I have no idea. I am answering to your proposal from the different angle, as a person who spent some efforts maintaining VFS interfaces. I object against interface abuse, and point out a fragility of the approach. --4tkssvp36SW1tyIS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR7AnuAAoJEJDCuSvBvK1BHEwQAIkn10EF7RpCqfe6DDOLA8/N eZc0Ij5YvlH6qCsr843TWdeKP5Kcs4ygRoEL2oJj2gTzVaFxsECe0OmCHPkowXTV 6IUWG/zUOZWNfIas2s+Rra4aTyeOMMk4Ud2FVv0InISVCmEGiVkPGnUHpu3iNxvb X6doIySKaP7m2JzvS7zcFLh1Ju0VZdj5f/C3jjEes1qv5KTaC9yxxGlrWHk6Bx26 X9vPLTX64lR8gQsHpGWWFwc+aRuxXShjoxoH6t1J2RVP1g1RJca7HdRioc/EMQQ4 tXQwMmic+pM+7LMCDAf8jKVFAe/UKqKgYpITiKOiNht4MufSUsbYBH2hzgCANlp3 jUfospcMKqz/WPq48r+o+THs+BF5fIPIu0bCi+zpodh1hr1ZiohbOMcZ5biL452P h3SNVQ8dK+hloHpI+XhYtpl4YY3ge7wDXnbrl7nu58EfRFy7EodQczZB33k+xhbf BEXVKK/52MV4rczRW74LLsMk8i2j0QAiVFpfzU4nDlkrCLkYdV0X9+u4TwH/7i2H X51v3aLzWfX9Uiz+yHdunWp+AxU5+iLWb31l38fGTf/LyiJYU1zeWiSxq0nFwiPk 9Gf5ODtvH3hrGv4UVq5yGXwReuTGXeFlIFalHL8WJ2QzBLFiRRjkX/EJBeFBLG8G 4M6Saa9SD80VlX4UujTJ =NjnG -----END PGP SIGNATURE----- --4tkssvp36SW1tyIS--