From owner-freebsd-fs@FreeBSD.ORG Thu Sep 29 01:36:49 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 AB42D106566B; Thu, 29 Sep 2011 01:36:49 +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 470348FC0A; Thu, 29 Sep 2011 01:36:48 +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 p8T1aZVY088478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2011 04:36:35 +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 p8T1aZPm050811; Thu, 29 Sep 2011 04:36:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p8T1aZUG050810; Thu, 29 Sep 2011 04:36:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 Sep 2011 04:36:35 +0300 From: Kostik Belousov To: Kirk McKusick Message-ID: <20110929013635.GG1511@deviant.kiev.zoral.com.ua> References: <201109280019.p8S0JVUW067163@chez.mckusick.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ssSfcPohcXNs3135" Content-Disposition: inline In-Reply-To: <201109280019.p8S0JVUW067163@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.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Garrett Cooper , freebsd-fs@freebsd.org, Xin LI , bug-followup@freebsd.org Subject: Re: PR kern/161016 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: Thu, 29 Sep 2011 01:36:49 -0000 --ssSfcPohcXNs3135 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 27, 2011 at 05:19:31PM -0700, Kirk McKusick wrote: > > Date: Sun, 25 Sep 2011 12:07:18 -0700 > > From: Garrett Cooper > > To: lev@freebsd.org > > Cc: freebsd-fs@freebsd.org, Xin LI , current@freeb= sd.org > > Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? > >=20 > > 2011/9/25 Lev Serebryakov : > > > Hello, Garrett. > > > You wrote 25 =3DD3=3DC5=3DCE=3DD4=3DD1=3DC2=3DD2=3DD1 2011 =3DC7., 12= :06:05: > > > > > >> =3D9A =3D9A Talking to Xin yesterday, he was convinced that this was= a > > >> filesystem//kern bug. Before I file a PR, I'm wondering if anyone el= se > > >> has seen this issue.. > > > =3D9AYes, and I posted message about it in embedded@ (Message-ID > > > <1175277342.20110821215629@serebryakov.spb.ru>), I've got additional > > > question from Warner Losh about base (underlying) file system, without > > > any additional reaction. > >=20 > > Thanks for the comments Adrian and Lev! I've filed PR 161016 to track > > the issue, because it might be due to changes in the SU code, md, or a > > subtle race condition in umount (highly unlikely, but it's been > > noted). > > -Garrett > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >=20 > I have taken responsibility for working on this bug report (PR kern/16101= 6). >=20 > I propose the following change to correct it: >=20 > Index: sys/kern/vfs_mount.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/vfs_mount.c (revision 225807) > +++ sys/kern/vfs_mount.c (working copy) > @@ -1227,18 +1227,6 @@ > mp->mnt_kern_flag |=3D MNTK_UNMOUNTF; > error =3D 0; > if (mp->mnt_lockref) { > - if ((flags & MNT_FORCE) =3D=3D 0) { > - mp->mnt_kern_flag &=3D ~(MNTK_UNMOUNT | MNTK_NOINSMNTQ | > - MNTK_UNMOUNTF); > - if (mp->mnt_kern_flag & MNTK_MWAIT) { > - mp->mnt_kern_flag &=3D ~MNTK_MWAIT; > - wakeup(mp); > - } > - MNT_IUNLOCK(mp); > - if (coveredvp) > - VOP_UNLOCK(coveredvp, 0); > - return (EBUSY); > - } > mp->mnt_kern_flag |=3D MNTK_DRAINING; > error =3D msleep(&mp->mnt_lockref, MNT_MTX(mp), PVFS, > "mount drain", 0); >=20 > The things to check for are: >=20 > 1) That it fixes the EBUSY on unmount. >=20 > 2) That it does not cause unmount to hang. >=20 > I would appreciate feedback as to whether this fix helps. I think the item 2) should be tested mostly on the hung NFS server. I understand what you are doing, you do not want a transient mount point busy caller to fail the unmount. But my belief is that this is the intended mode of operation for non-forced unmounts. As I compare the original bug report and your change, the reason that UFS gives spurious EBUSY on soft unmounts is that SU code busies mp around some processing. Is my guess right ? Then, restoring some amount of sync(2) before the unmount would be useful, please see r222466 for the most likely reason why the issue appeared. Might be, the best route would be to add a kludge mnt_flag that request dounmount() to do a VFS_SYNC() before checking for the busy holder ? --ssSfcPohcXNs3135 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6Dy6MACgkQC3+MBN1Mb4hhwQCgzuj/4OgfYVYgROYIjridzOs5 wooAnje938vnGjgW9UincSwhn0+Sj7Fq =4iJ6 -----END PGP SIGNATURE----- --ssSfcPohcXNs3135--