From owner-freebsd-fs@FreeBSD.ORG Thu Aug 29 12:50:56 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 2F6FEB40; Thu, 29 Aug 2013 12:50:56 +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 BA520248A; Thu, 29 Aug 2013 12:50:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEAFVDH1KDaFve/2dsb2JhbABagzxRgye7dIENgUF0giQBAQEEAQEBICsgCwUWDgoCAg0ZAikBCSYGCAcEARwEh2AMpl6SL4EpjRKBBTQHgmiBNAOVKoN4kDeDPCAygQM5 X-IronPort-AV: E=Sophos;i="4.89,983,1367985600"; d="scan'208";a="48042414" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 29 Aug 2013 08:50:40 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 25CD7B4042; Thu, 29 Aug 2013 08:50:40 -0400 (EDT) Date: Thu, 29 Aug 2013 08:50:40 -0400 (EDT) From: Rick Macklem To: Mark Felder Message-ID: <1440314933.15156431.1377780640143.JavaMail.root@uoguelph.ca> In-Reply-To: <1377779585.6006.15542805.33D96D05@webmail.messagingengine.com> Subject: Re: 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: 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: Thu, 29 Aug 2013 12:50:56 -0000 Mark Felder wrote: > On Wed, Aug 28, 2013, at 19:15, 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(). > > > > 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. > > > > always mount your nfs with options "soft,intr" or you'll run into > this > :) I'm not sure if your smiley is because you already know what I think of "soft, intr", but... Application software generally doesn't expect I/O syscalls (read, write...) to fail with ETIMEDOUT or EINTR. As such, I would never use "soft", except maybe for some read-only volume where intermittent failures aren't an issue. As for "intr", I believe that processes can get stuck in uninterruptible situations when they are waiting for a buffer/page that is in use by another thread (that no "intr" signal has been issued for). However, this just means the process won't "interrupt", so so long as there isn't an unexpected interruption caused by a signal, it could be ok. Finally, neither of these options are safe to use for NFSv4, because operations that manipulate state (like locks) cannot be safely interrupted, since they will leave the lock in an undefined state, at least for the FreeBSD server. So, at least for NFSv4, a forced dismount is a necessary alternative. Personally, when I was a sysadmin, I tried to make sure my NFS server and network ran reliably and always used hard mounts (no "intr, soft") to avoid the issue. rick > _______________________________________________ > 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" >