From owner-freebsd-fs@FreeBSD.ORG Thu Aug 29 22:31:34 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3B41CCEB for ; Thu, 29 Aug 2013 22:31:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A66732F66 for ; Thu, 29 Aug 2013 22:31:33 +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 r7TMVSeP021814; Fri, 30 Aug 2013 01:31:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r7TMVSeP021814 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r7TMVSR2021813; Fri, 30 Aug 2013 01:31:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Aug 2013 01:31:28 +0300 From: Konstantin Belousov To: Rick Macklem Subject: Re: fixing "umount -f" for the NFS client Message-ID: <20130829223128.GP4972@kib.kiev.ua> References: <20130829005616.GH4972@kib.kiev.ua> <2075428996.15437999.1377814901677.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uFc9xn1y3ioKq896" Content-Disposition: inline In-Reply-To: <2075428996.15437999.1377814901677.JavaMail.root@uoguelph.ca> 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 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: Thu, 29 Aug 2013 22:31:34 -0000 --uFc9xn1y3ioKq896 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 29, 2013 at 06:21:41PM -0400, Rick Macklem wrote: > Kostik wrote: > > On Wed, Aug 28, 2013 at 08:15:27PM -0400, Rick Macklem wrote: > > > I've been doing a little more testing of "umount -f" for NFS > > > mounts and they seem to be working unless some other process/thread > > > has busied the file system via vfs_busy(). > > >=20 > > > Unfortunately, it is pretty easy to vfs_busy() the file system > > > by using a command like "df" that is stuck on the unresponsive > > > NFS server. > > >=20 > > > The problem seems to be that dounmount() msleep()s while > > > mnt_lockref !=3D 0 before calling VFS_UNMOUNT(). > > >=20 > > > If some call into the NFS client was done before this > > > while (mp->mnt_lockref) loop with msleep() in it, it > > > can easily kill off RPCs in progress. (It currently > > > does this in nfs_unmount() using the newnfs_nmcancelreqs() > > > call. > > >=20 > > > In summary: > > > - Would it be appropriate to add a new vfs_XXX method that > > > dounmount() would call before the while() loop for the > > > forced dismount case? > > > (The default would be a no-op and I have no idea if any > > > file system other than NFS would have a use for it?) > > > Alternately, there could be a function pointer set non-NULL > > > that would specifically be used by the NFS client for this. > > > This would avoid adding a vfs_XXX() method, but would mean > > > an NFS specific call ends up in the generic dounmount() code. > > >=20 > > > Anyone have comments on this? > > >=20 > > Yes, I do. I agree with adding the pre-unmount vfs method. > > This seems to be the cleanest solution possible. > >=20 > I've attached a patch. It is also at > http://people.freebsd.org/~rmacklem/forced-dism.patch > in case the attachment gets lost. > I don't really like doing the MNT_IUNLOCK(), MNT_ILOCK() before/after > the VFS_KILLIO() call, but I couldn't see any better way to do it and > it looks safe to do so, at least for the forced case. Might be, call it VFS_PURGE() ? I suggest to move the call to the VFS_KILLIO after the MNTK_DRAINING is set, to avoid getting new references after the current i/o transactions are stopped. You would need to set MNTK_DRAINING unconditionally. Also, it probably makes sense to replace the if (mnt_lockref) with while (). >=20 > I assume I would also need to bump __FreeBSD_version (and maybe VFS_VERSI= ON?). I think you could avoid it. --uFc9xn1y3ioKq896 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSH8u/AAoJEJDCuSvBvK1B1dsQAKlRITSVql/vHTUinsxv6hq5 Qaq8EdsVyTTwoUi2fqp1Vf91B+K0prFiWEwJkJHfLIMzKCGT47wM30pWQvDRZ+Xl OcrOLilWj3WgdolfQRubNH35xlO5WhQOSxuPslhzyIvQOUninRUBXWQZy5ptq4tG nAHHLmlfviAN5gfu3gKoSizfDoB0aJwC0MoLZMD72ta4CVArmkK/qQMxNbZn+w7O U7/Owm1HCZKNyAukdLIpmqEViusCDpvwtfNR3wi5JaJLE+leT8K/vcmCivLH9QqP Lx/SppNsW9a/temHpSs4mBK7pR+awqF2k0cVYIoquSyDk1xaMsqYQOwWhYDbzm51 CSsm89c0TNZJyuQxfCouNVg7p3pzrRjyC5EE+Azu9T+gkTNq+PQaVr6G3DOQdEdm 1DbxAiBK5EC2yfdQREf9twRcXVB2Qor8IEEXeuyzX3P+s+9NI2RqrpXyKRC0c4We KkNdwHkakhA8PQZl64x8lP8ugvye7JewYa0gTORehBwR/fuAfMqhYfWVgoAYKH0b AfW1Zx3tnSN3gX0FVM761Q+hZRJ3Ov76obsSS1pr+WmNEOwtdzdCC4bS0xqx21+B WCR/Fqf+HMd8L6KJLXbG7zDeuZyYddR5Pg4o3f9lQ8SMRCxEZFRyrnGByP8RfHaK XwuZaen7vIO4wF30Wjtq =+HoH -----END PGP SIGNATURE----- --uFc9xn1y3ioKq896--