Need to force sync(2) before umounting UFS1 filesystems?

Kirk McKusick mckusick at mckusick.com
Thu Sep 29 15:31:26 UTC 2011


> Date: Thu, 29 Sep 2011 12:04:24 +0200
> From: Attilio Rao <attilio at freebsd.org>
> To: Kirk McKusick <mckusick at mckusick.com>
> Cc: Garrett Cooper <yanegomi at gmail.com>, freebsd-fs at freebsd.org,
>         Xin LI <delphij at freebsd.org>
> Subject: Re: Need to force sync(2) before umounting UFS1 filesystems?
> 
> 2011/9/29 Kirk McKusick <mckusick at mckusick.com>:
> > 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


More information about the freebsd-fs mailing list