From owner-freebsd-fs@FreeBSD.ORG Tue Oct 11 10:23:35 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C27A1106564A; Tue, 11 Oct 2011 10:23:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 455608FC0C; Tue, 11 Oct 2011 10:23:34 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p9BANVLY060155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 13:23:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p9BANVJT023515; Tue, 11 Oct 2011 13:23:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p9BANVx3023514; Tue, 11 Oct 2011 13:23:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Oct 2011 13:23:31 +0300 From: Kostik Belousov To: Kirk McKusick Message-ID: <20111011102331.GW1511@deviant.kiev.zoral.com.ua> References: <201110110756.p9B7ul0g051037@chez.mckusick.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y2BITh8TegacRQ/d" Content-Disposition: inline In-Reply-To: <201110110756.p9B7ul0g051037@chez.mckusick.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Garrett Cooper , Attilio Rao , Xin LI , freebsd-fs@freebsd.org Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 10:23:35 -0000 --Y2BITh8TegacRQ/d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 11, 2011 at 12:56:47AM -0700, Kirk McKusick wrote: > > Date: Mon, 10 Oct 2011 19:12:59 -0700 > > From: Garrett Cooper > > To: Kostik Belousov > > Cc: Kirk McKusick , Attilio Rao , > > Xin LI , freebsd-fs@freebsd.org > > Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? > >=20 > > 2011/10/10 Kostik Belousov : > >=20 > > > The real case to test is the NFS mount which is wedged due to > > > hung/unresponsive NFS server. I have high suspect that the patch > > > could introduce the unkillable hung unmount process. > >=20 > > It blocked, but I could ^C it perfectly fine. I tested it via: > >=20 > > Setup: > > 1. Started up FreeNAS 8.x image; it acquired an IP from my server with > > dhcp-75.local. > >=20 > > Test 1: > > 1. mount -t nfs dhcp-75:/mnt/tank /mnt/nfs/ from my test workstation. > > 2. Paused VM. > > 3. umount /mnt/nfs (the command blocked). > > 4. ^C. > > 5. mount | grep /mnt/nfs showed nothing (it had unmounted). > >=20 > > Test 2: > > 1. mount -t nfs dhcp-75:/mnt/tank /mnt/nfs/ from my test workstation (b= locked). > > 2. Opened up another ssh session and cd'ed to /mnt/nfs . > > 3. Paused VM. > > 4. umount /mnt/nfs . It failed with EBUSY. > > 5. mount | grep /mnt/nfs showed that it was still mounted, as expected. > >=20 > > So unless there are buffers still waiting to be written out to an > > NFS share, or other reasons that would prevent the NFS share from > > being fully released, I doubt the proposed behavior is really > > different from previous versions of FreeBSD. > > Thanks, > > -Garrett >=20 > Given the testing that has been done and our discussion about deadlocks, I am not sure that it was adequate. If it was not obvious, my main concern is the nfs client that busied the mount point and waiting for the wedged server rpc response. > I believe that I should proceed to check in my originally proposed > change. Notably the one that simply deleted the !=3D MNT_FORCE > conditional. However, there is no harm in using my revised version > that releases the covered vnode before draining vfs_busy, and there > might be some future case where that would be a necessary thing to do. What is the future case where you intend to break the order between vfs_busy() and vnode locks ? >=20 > Speak up if you think I should not proceed to check in this change. > Also, let me know if you have thoughts on which version I should use. If commmitting any of two changes, I would prefer to see the minimal one, which does not unlock the covered vnode. --Y2BITh8TegacRQ/d Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6UGSMACgkQC3+MBN1Mb4ivDQCgj68AvEPpR7R91lqUxwaangpI /pwAoNuKrFsFj7uEB86btnHHvrXKjSQZ =MY9v -----END PGP SIGNATURE----- --Y2BITh8TegacRQ/d--