From owner-freebsd-fs@FreeBSD.ORG Thu Sep 29 10:04:26 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 DCC7F106564A for ; Thu, 29 Sep 2011 10:04:26 +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 4F4E28FC16 for ; Thu, 29 Sep 2011 10:04:25 +0000 (UTC) Received: by wyj26 with SMTP id 26so128806wyj.13 for ; Thu, 29 Sep 2011 03:04:25 -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; bh=Kw9hO6oh+/Fh2RRPEikdRSS91q+h0XV4Sp+BPVHZC2w=; b=YdIlrWY/83t5vhl/qKdMdkr0Hc5naplwNZup2iV8P3ZSZSsOQRYLS1BHX/UlBzwbcd ZGD74nJd9jVfGXu5RhaZvEq+PTfrb5nXj5tXa7rQUvw4oa4PXa+tT6nMszA3E0Vm5dR5 YFnEvTIght4RchH7yaM7AzlMJ+xDEb2EcgXlM= MIME-Version: 1.0 Received: by 10.216.203.69 with SMTP id e47mr8197082weo.57.1317290664950; Thu, 29 Sep 2011 03:04:24 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Thu, 29 Sep 2011 03:04:24 -0700 (PDT) In-Reply-To: <201109290620.p8T6KGCl057169@chez.mckusick.com> References: <201109290620.p8T6KGCl057169@chez.mckusick.com> Date: Thu, 29 Sep 2011 12:04:24 +0200 X-Google-Sender-Auth: bKv4SGopmXn09ZjMvp037WTWOW8 Message-ID: From: Attilio Rao To: Kirk McKusick Content-Type: text/plain; charset=UTF-8 Cc: Garrett Cooper , freebsd-fs@freebsd.org, Xin LI 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: Thu, 29 Sep 2011 10:04:26 -0000 2011/9/29 Kirk McKusick : > Hi Attilio, > > I have been looking into the problem described below and since you > appear to be the person that put in the change in question, I would > like to get you opinion on what (if anything) should be changed here. Kirk, please note that I didn't add/change anything wrt. that codepath. In the old code it was present a lockmgr() acquisition with LK_DRAIN and LK_NOWAIT. This means that if the lockmgr() lock on the struct mount was already held by any other consumer it was going to fallback in the codepath you outlined in the patch immediately, rather than just sleeping (and note that LK_NOWAIT was just passed in the case of a non-forced unmount). Said that, I don't really have an objection with making the forced unmount case as the default, but I still didn't go through the whole thread you outlined and I don't have any context on it, thus I'm not sure if this is the right approach or not. If you want to share more context on the problem you are trying to solve by switching that policy we may discuss this too, but in general I don't have a problem about adopting forced unmount policy on unmount for all the cases. Attilio -- Peace can only be achieved by understanding - A. Einstein