From owner-freebsd-questions@FreeBSD.ORG Tue Dec 13 00:06:15 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BF481065678 for ; Tue, 13 Dec 2011 00:06:15 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id EAD8B8FC17 for ; Tue, 13 Dec 2011 00:06:14 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 747A65C24 for ; Tue, 13 Dec 2011 10:18:37 +1000 (EST) Message-ID: <4EE6964D.8080201@herveybayaustralia.com.au> Date: Tue, 13 Dec 2011 10:03:25 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <4EE32BB6.3020105@herveybayaustralia.com.au> <4EE38454.3020307@otenet.gr> <4EE3D1F0.60500@herveybayaustralia.com.au> <4EE3DA85.4070903@herveybayaustralia.com.au> <20111211002348.56497fde@gumby.homeunix.com> <4EE442DC.7080107@herveybayaustralia.com.au> <20111212180953.2bc4af97@gumby.homeunix.com> In-Reply-To: <20111212180953.2bc4af97@gumby.homeunix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 9.0 install and journaling X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 00:06:15 -0000 On 12/13/11 04:09, RW wrote: > On Sun, 11 Dec 2011 15:42:52 +1000 > Da Rock wrote: > >> On 12/11/11 10:23, RW wrote: >>> On Sun, 11 Dec 2011 08:17:41 +1000 >>> Da Rock wrote: >>> >>> >>>>> SUJ speeds up the check a lot, seconds as opposed to minutes. If >>>>> something happens to the journal, it falls back to a standard >>>>> fsck. >>>> But fsck needs to be run manually- I have users that can't do that, >>>> and the filesystem corrupts. Ergo gjournal; it boots up and fixes >>>> on the fly. So SU+J needs a manual fsck before booting proper or >>>> can it just boot and be done? >>> It's not very different; gjournal and SU both attempt to leave the >>> filesystem in an coherent state, but both still need a preen to >>> recover lost space. In either case the preen can fail requiring a >>> full fsck. >>> >>> Journalled SU make SU behave more like gjournal in that you can do a >>> fast foreground check which avoids the lengthy background fsck and >>> avoids deferring the handling of unexpected inconsistencies to the >>> next boot. >>> >> Yes, but I don't do a fsck to recover gjournal- it has a miniscule >> blurp for a nanosecond and prints a message at boot and thats it. > > > If the filesystem is mounted via fstab the fsck is normally done > automatically. You may not have noticed this because if nothing needs > doing fsck_ufs can mark a gjournal filesystem clean instantaneously. > > There are two other possibilities. The first is that it may spend some > time recovering orphaned files; this is much faster that a full fsck > but it's still seconds or minutes. The second is that the journal sync > may have failed in which case fsck terminates with "UNEXPECTED > INCONSISTENCY" which requires a full fsck. This is similar to SU. In > either case you only need a full fsck when things haven't worked out in > line with the theory. > > >> Is >> it the same with su+j? If it does then I'll drop gjournal (and the >> performance hit) and I'll use su+j when I jump to 9.0. > The SU equivalent of the journal sync is done before the crash > happens. With SU you can have an instantaneous foreground fsck by > deferring the recovery of lost files until the background check that > runs after bootup. Journalling SU eliminates the few minutes > of sluggish disk IO that that can cause. > > I've been disappointed by gjournal, the performance hit isn't as bad as > background fsck but it is substantial and permanent, rather than a few > minutes hare and there. I was hoping that gjournal would be more robust, > but I've seen the occassional "UNEXPECTED INCONSISTENCY" just like I > have with SU. > This is going to sound odd, I know, but what does your fstab look like with gjournal? I've only done /var and /usr like this: /dev/ad4s1e.journal /usr ufs rw,async 2 2 The only message that comes up for me after a crash is "consistent" or "clean". No wait, no fsck. The performance isn't exactly lightning though... :)