From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 03:23:29 2010 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 E04C2106566C for ; Fri, 23 Apr 2010 03:23:28 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas01p.mx.bigpond.com (nskntmtas01p.mx.bigpond.com [61.9.168.137]) by mx1.freebsd.org (Postfix) with ESMTP id 67A9A8FC08 for ; Fri, 23 Apr 2010 03:23:28 +0000 (UTC) Received: from nskntotgx02p.mx.bigpond.com ([124.188.161.100]) by nskntmtas01p.mx.bigpond.com with ESMTP id <20100423032327.ZJFP12504.nskntmtas01p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com>; Fri, 23 Apr 2010 03:23:27 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20100423032326.ZJEH2010.nskntotgx02p.mx.bigpond.com@duncan.reilly.home>; Fri, 23 Apr 2010 03:23:26 +0000 Date: Fri, 23 Apr 2010 13:23:26 +1000 From: Andrew Reilly To: David N Message-ID: <20100423032326.GB1347@duncan.reilly.home> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <20100421024803.GA25701@duncan.reilly.home> <20100421085228.GA27892@duncan.reilly.home> <20100421095054.GA28619@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Fri, 23 Apr 2010 03:23:26 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.4BD112AE.0171,ss=1,fgs=0 X-SIH-MSG-ID: qRs3FtHuXAD+xDJw0jPvNAJ+xA/u8yI74J0WRdJsoQQZSkfduMHeU7zhKrMwgcz21j1cNhmPPGIqYav0X4/QsuM= Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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: Fri, 23 Apr 2010 03:23:29 -0000 On Wed, Apr 21, 2010 at 09:47:32PM +1000, David N wrote: > Sorry, i forgot the gm0e and ad8s1a is a label. > can you show me the bsdlabel for the mirror/gm0 and ad8s1 bsdlabel: unable to get correct path for mirror/gm0: No such file or directory Sorry for the confusion: gm0e is a gmirror label that I made up, to remind me that the mirror components are the "e" partition of the underlying drives: $ gmirror status Name Status Components mirror/gm0a COMPLETE ad4s1a ad6s1a mirror/gm0d COMPLETE ad4s1d ad6s1d mirror/gm0e COMPLETE ad4s1e ad6s1e # /dev/ad8s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2930277089 16 unused 0 0 c: 2930277105 0 unused 0 0 # "raw" part, don't edit > Also there is a overflow with the ad10s1 and journal Hmm. I'm not sure about that, but it does look as though I should have used ad10s1a as the provider, rather than just ad10s1. I bsdlabel'd ad10s1 (which is where the a and c partitions are correct), but then I went and gjournal labelled ad10s1, rather than ad10s1a. I'm pretty sure that the label that was displayed for ad10s1.journal is just something that was poking through, since the journal metadata is at the end of the space. > When i first started, it kept complaining. For slices, you have the > ad10, put the s1 slice in, then you gjournal that, bsdlabel the > .journal. Then change the label to the mediasize of the journal/512. > > So in your case your bsdlabel should be 749081051136 / 512 = > 1463048928 with offset of 0. > c: 1465146081 - (what is expected)1463048928 = 2097153*512 = > 1073742336 (which is roughly 1GB, your journal size) > Your c label is over by about 1GB which means the fs is writing over > the journal part sometimes and the journal writing over the data > sometimes, which would lead to the journal overflow and journal/data > corruption. I'll have another go at spinning that all around this weekend. It isn't clear to me when or why the file system pays attention to a bsdlabel. Most of my file systems are on GEOM providers that are *not* bsdlabelled, and that doesn't seem to worry them. In this case, the c partition that seems to overhang the journal space is *not* related to or used by the file system, or at least shouldn't be. > I hope i haven't confused you. I started to gjournal the slices as > gjournalling the bsdlabels you needed to decrease your bsdlabel by 1 > (thats where the GEOM data was stored) and gave me too many headaches. > > If you gjournal the slices, then bsdlabel them, you just change the c > label to (.journal media size)/512 offset 0, and it all works. Reckon I'm going to be switching over to SUJ as soon as possible: hopefully it'll have a different set of gotchas. Thanks for the help! Cheers, -- Andrew