From owner-freebsd-fs@FreeBSD.ORG Thu Aug 29 00:15:28 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB7742B2; Thu, 29 Aug 2013 00:15:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6F142230D; Thu, 29 Aug 2013 00:15:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEABqSHlKDaFve/2dsb2JhbABahA2DJ7txgQ2BOXSCTgRSNQINGQJfiBSnCZIrgSmOBzSCb4ExA6lSgzwggW4 X-IronPort-AV: E=Sophos;i="4.89,978,1367985600"; d="scan'208";a="47975341" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 28 Aug 2013 20:15:27 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4F9B8B4042; Wed, 28 Aug 2013 20:15:27 -0400 (EDT) Date: Wed, 28 Aug 2013 20:15:27 -0400 (EDT) From: Rick Macklem To: freebsd-fs Message-ID: <2057976640.15042430.1377735327317.JavaMail.root@uoguelph.ca> Subject: fixing "umount -f" for the NFS client MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Kostik Belousov 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 00:15:28 -0000 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(). 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. The problem seems to be that dounmount() msleep()s while mnt_lockref != 0 before calling VFS_UNMOUNT(). 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. 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. Anyone have comments on this? Thanks, rick