From owner-freebsd-fs@FreeBSD.ORG Thu Sep 29 15:31: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 D86A1106566C; Thu, 29 Sep 2011 15:31:26 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) by mx1.freebsd.org (Postfix) with ESMTP id 625E78FC08; Thu, 29 Sep 2011 15:31:26 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id p8TFVRka077669; Thu, 29 Sep 2011 08:31:28 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201109291531.p8TFVRka077669@chez.mckusick.com> To: Attilio Rao In-reply-to: Date: Thu, 29 Sep 2011 08:31:27 -0700 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com 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 15:31:26 -0000 > Date: Thu, 29 Sep 2011 12:04:24 +0200 > From: Attilio Rao > To: Kirk McKusick > Cc: Garrett Cooper , freebsd-fs@freebsd.org, > Xin LI > Subject: Re: Need to force sync(2) before umounting UFS1 filesystems? > > 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 Thanks for providing a bit more of the history on this codepath. Since 9-stable has now been branched, I believe that the best path forward is to check this change into head and let it sit there for several months so that we can get some experience with it. If it causes folks problems we can back it out. If it does not cause problems, then we can MFC it to 9-stable. Does this seem like a reasonable approach? Kirk McKusick