From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 16:08:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F020106564A; Tue, 30 Jun 2009 16:08:02 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4DC8FC17; Tue, 30 Jun 2009 16:08:01 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz12 with SMTP id 12so227648bwz.43 for ; Tue, 30 Jun 2009 09:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=TDD6WF2gXafy9CTKQtZFhm7aP2oicr1uifWy2DcgTEA=; b=bYuV7FCOdCDy8tsTrXE29kHVsr+qsAI1X9Xbwu1olYI6i5vFnSXcxAkuTkVDMCGR60 78dCYBCkbtUOgeYSDFZe6XR9Ymky4CYeHgHyX9iRzEryN/XO/HHGRGFcjM50y0xhapRW Rn5FF917qFQKnbfMXHbNtu8wW3scoYvsJt8k4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=j66oOopeg0sCwNkHTfypcesmDftb8R7mZFxJ/AtiKpGiPRaLI5qF9MH87wl9D1rCpX oswUiXlPPP5D0WroM+QbA1jg22ryF7xPjIPhKxGV3s1f0exv+rTC+5JBPyDmkhQI4Cs+ HsIXUDKlPJTH98x7bQsD7OJH4VHEwS2v4W1KQ= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.113.136 with SMTP id a8mr5381699faq.76.1246378080211; Tue, 30 Jun 2009 09:08:00 -0700 (PDT) In-Reply-To: References: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> Date: Tue, 30 Jun 2009 18:08:00 +0200 X-Google-Sender-Auth: 1a771cec11f35e25 Message-ID: <3bbf2fe10906300908p6b0f314di25bab46b03b5933a@mail.gmail.com> From: Attilio Rao To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:08:02 -0000 2009/6/30 Rick Macklem : > > > 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().) Sorry for not answering and I still didn't read this thread at all, I just wanted to let you know that this msleep is skipped for the force unmount, it should just happen in a normal unmount case. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein