From owner-freebsd-fs@FreeBSD.ORG Tue Jun 30 15:59:05 2009 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 867BE106567D; Tue, 30 Jun 2009 15:59:05 +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 100E78FC25; Tue, 30 Jun 2009 15:59:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJrTSUqDaFvL/2dsb2JhbADQFoQPBYE3 X-IronPort-AV: E=Sophos;i="4.42,317,1243828800"; d="scan'208";a="39813688" Received: from nile.cs.uoguelph.ca ([131.104.91.203]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 Jun 2009 11:59:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 1E6638D4116; Tue, 30 Jun 2009 11:59:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at nile.cs.uoguelph.ca Received: from nile.cs.uoguelph.ca ([127.0.0.1]) by localhost (nile.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMeyVdoHsslR; Tue, 30 Jun 2009 11:59:03 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 01AA38D40FF; Tue, 30 Jun 2009 11:59:03 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5UG1LW11918; Tue, 30 Jun 2009 12:01:21 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 30 Jun 2009 12:01:21 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Attilio Rao In-Reply-To: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> Message-ID: References: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation 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, 30 Jun 2009 15:59:06 -0000 On Mon, 29 Jun 2009, Attilio Rao wrote: > > While that should be real in principle (immediate shutdown of the fs > operation and unmounting of the partition) it is totally impossible to > have it completely unsleeping, so it can happen that also umount -f > sleeps / delays for some times (example: vflush). > Currently, umount -f is one of the most complicated thing to handle in > our VFS because it puts as requirement that vnodes can be reclaimed in > any moment, adding complexity and possibility for races. > > What's the fix for your problem? > >From other responses, it does look like pursuing this is appropriate and that current behaviour is considered a bug. I should have noted in the previous email that I suspected that my simple patch didn't handle all cases, which I have just determined via testing. Unfortunately, the thread doing "umount" can also get stuck in an msleep() while waiting for the mnt_lockref to go to 0, which happens before the VFS_UNMOUNT() call. (mnt_lockref gets incremented by various system calls that call vfs_busy().) I think I can fix this in the experimental nfsv4 client, since it has a kernel thread that can check for MNTK_UNMOUNTF being set and then kill off the RPCs in progress, but that won't help the regular client. It's starting to look like too much work for FreeBSD8, but sounds like it is worth pursuing. (Appologies to anyone that thought I would have it all fixed in a day or two.) rick