From owner-freebsd-current@FreeBSD.ORG Thu May 27 14:02:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 236031065672; Thu, 27 May 2010 14:02:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D37748FC13; Thu, 27 May 2010 14:02:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 84B3746B66; Thu, 27 May 2010 10:02:10 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id D6D5F8A021; Thu, 27 May 2010 10:02:09 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 27 May 2010 09:33:42 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005270933.42760.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 27 May 2010 10:02:09 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Marcelo/Porks , Garrett Cooper , Jeff Roberson , current@freebsd.org Subject: Re: SUJ Changes 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: Thu, 27 May 2010 14:02:11 -0000 On Wednesday 26 May 2010 7:56:24 pm Garrett Cooper wrote: > On Wed, May 26, 2010 at 3:52 PM, Marcelo/Porks wrote: > > On 5/25/10, Marcelo/Porks wrote: > >> Hi! I tested the r208241 and it's seems to be ok but this calls my > >> atention to other thing: Could I disable de SU when the SUJ is > >> enabled? > >> > >> I did some tests and seems that I can do this (logs bellow). > >> > >> But will SUJ work properly with SU disabled? > > > > Hi guys. I'm not sure if I could call this a problem but I can disable > > SU when SUJ is enabled, so SUJ will remain enabled and SU will be > > disabled. > > > > #tunefs -j enable /dev/device > > #tunefs -n disable /dev/device > > > > I did a patch for sbin/tunefs/tunefs.c that disable SUJ when the user > > disable SU. Maybe this will be useful for some of you. > > > > Thanks. > > > > > > Index: sbin/tunefs/tunefs.c > > =================================================================== > > --- sbin/tunefs/tunefs.c (revision 208580) > > +++ sbin/tunefs/tunefs.c (working copy) > > @@ -460,6 +460,14 @@ > > if ((~sblock.fs_flags & FS_DOSOFTDEP) == FS_DOSOFTDEP) > > warnx("%s remains unchanged as disabled", name); > > else { > > + /* also disable SUJ */ > > + if ((sblock.fs_flags & FS_SUJ) == FS_SUJ) { > > + warnx("soft updates journaling > > will be disabled too"); > > + journal_clear(); > > + sblock.fs_flags &= ~FS_SUJ; > > + sblock.fs_sujfree = 0; > > + warnx("remove .sujournal to > > reclaim space"); > > + } > > sblock.fs_flags &= ~FS_DOSOFTDEP; > > warnx("%s cleared", name); > > } > > I think that it makes sense to have this as a force option as someone > may want to retain their journal instead of disposing of it > automatically. I'm not sure that really makes sense. As as you do any update to the filesystem the journal becomes out of date, and attempting to replay it could corrupt the filesystem. Instead, I think that attempting to disable SU if SUJ is enabled should just fail with an error message. The sysadmin can then choose to disable both SUJ and SU if desired. -- John Baldwin