From owner-freebsd-fs@FreeBSD.ORG Tue Oct 11 12:04:04 2011 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 1486510657B7; Tue, 11 Oct 2011 12:04:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 048318FC2B; Tue, 11 Oct 2011 12:03:57 +0000 (UTC) Received: by wyj26 with SMTP id 26so10844263wyj.13 for ; Tue, 11 Oct 2011 05:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=uXh3kmJbzmqJfqqwus6WXgO7cV+DJqUQgW+AEv9doq4=; b=WFRwNG4hFa5cHybxbB9M5JVpQuoZe1tgsiKKzQWh25BktM5obgq8qq+EWvjsZaB9bu iWLHNFg0eD/UmgJtSZxz7jqra2C7uu3d/9yCcXGWKDhqhUM1IBu4FZCFzVsq/NouEV/t nCtUoHwThZZBFEzH3fhZ6Z0Jcj9TdwEen1Hf0= MIME-Version: 1.0 Received: by 10.216.134.201 with SMTP id s51mr747086wei.27.1318334637047; Tue, 11 Oct 2011 05:03:57 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Tue, 11 Oct 2011 05:03:56 -0700 (PDT) In-Reply-To: <20111011102331.GW1511@deviant.kiev.zoral.com.ua> References: <201110110756.p9B7ul0g051037@chez.mckusick.com> <20111011102331.GW1511@deviant.kiev.zoral.com.ua> Date: Tue, 11 Oct 2011 14:03:56 +0200 X-Google-Sender-Auth: ySK5opZ5kNVbDILb5RuCer8aXqI Message-ID: From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , Garrett Cooper , Xin LI , freebsd-fs@freebsd.org Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? 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, 11 Oct 2011 12:04:05 -0000 2011/10/11 Kostik Belousov : > On Tue, Oct 11, 2011 at 12:56:47AM -0700, Kirk McKusick wrote: >> > Date: Mon, 10 Oct 2011 19:12:59 -0700 >> > From: Garrett Cooper >> > To: Kostik Belousov >> > Cc: Kirk McKusick , Attilio Rao , >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Xin LI , freebsd-fs@f= reebsd.org >> > Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? >> > >> > 2011/10/10 Kostik Belousov : >> > >> > > The real case to test is the NFS mount which is wedged due to >> > > hung/unresponsive NFS server. I have high suspect that the patch >> > > could introduce the unkillable hung unmount process. >> > >> > =C2=A0 =C2=A0 It blocked, but I could ^C it perfectly fine. I tested i= t via: >> > >> > Setup: >> > 1. Started up FreeNAS 8.x image; it acquired an IP from my server with >> > dhcp-75.local. >> > >> > Test 1: >> > 1. mount -t nfs dhcp-75:/mnt/tank /mnt/nfs/ from my test workstation. >> > 2. Paused VM. >> > 3. umount /mnt/nfs (the command blocked). >> > 4. ^C. >> > 5. mount | grep /mnt/nfs showed nothing (it had unmounted). >> > >> > Test 2: >> > 1. mount -t nfs dhcp-75:/mnt/tank /mnt/nfs/ from my test workstation (= blocked). >> > 2. Opened up another ssh session and cd'ed to /mnt/nfs . >> > 3. Paused VM. >> > 4. umount /mnt/nfs . It failed with EBUSY. >> > 5. mount | grep /mnt/nfs showed that it was still mounted, as expected= . >> > >> > =C2=A0 =C2=A0 So unless there are buffers still waiting to be written = out to an >> > NFS share, or other reasons that would prevent the NFS share from >> > being fully released, I doubt the proposed behavior is really >> > different from previous versions of FreeBSD. >> > Thanks, >> > -Garrett >> >> Given the testing that has been done and our discussion about deadlocks, > I am not sure that it was adequate. > > If it was not obvious, my main concern is the nfs client that busied > the mount point and waiting for the wedged server rpc response. > >> I believe that I should proceed to check in my originally proposed >> change. Notably the one that simply deleted the !=3D MNT_FORCE >> conditional. However, there is no harm in using my revised version >> that releases the covered vnode before draining vfs_busy, and there >> might be some future case where that would be a necessary thing to do. > What is the future case where you intend to break the order between > vfs_busy() and vnode locks ? > >> >> Speak up if you think I should not proceed to check in this change. >> Also, let me know if you have thoughts on which version I should use. > > If commmitting any of two changes, I would prefer to see the minimal one, > which does not unlock the covered vnode. I agree with Kostik, I don't see the point for dropping coveredvnode as long as the ordering is already set up, but I don't have objections to the 'minimal' change. Attilio --=20 Peace can only be achieved by understanding - A. Einstein