From owner-freebsd-fs@FreeBSD.ORG Fri Oct 8 03:22:17 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 8B9F81065670 for ; Fri, 8 Oct 2010 03:22:17 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (outbound02.telus.net [199.185.220.221]) by mx1.freebsd.org (Postfix) with ESMTP id 5111C8FC0C for ; Fri, 8 Oct 2010 03:22:17 +0000 (UTC) Received: from edtnaa04.telusplanet.net ([66.183.53.162]) by priv-edtnes28.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20101008032216.OEDG12546.priv-edtnes28.telusplanet.net@edtnaa04.telusplanet.net>; Thu, 7 Oct 2010 21:22:16 -0600 Received: from oliver.bc.lan (d66-183-53-162.bchsia.telus.net [66.183.53.162]) by edtnaa04.telusplanet.net (BorderWare Security Platform) with ESMTP id 90E392D12BF51450; Thu, 7 Oct 2010 21:22:16 -0600 (MDT) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id F2A7762A4; Thu, 7 Oct 2010 20:22:15 -0700 (PDT) Message-ID: <4CAE8E67.3080201@telus.net> Date: Thu, 07 Oct 2010 20:22:15 -0700 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Hywel Mallett References: <4CAD6A44.8010707@telus.net> <4813F683-1FF0-4DC4-9BC0-A512258C81CA@hmallett.co.uk> In-Reply-To: <4813F683-1FF0-4DC4-9BC0-A512258C81CA@hmallett.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=xzQzVvirXe8hBlOIrSXzJe7ImzW1YEUKF9Q3r6h0Mno= c=1 sm=0 a=p-OJjGmPj4MA:10 a=8nJEP1OIZ-IA:10 a=HNgjH8kF64GtJ7EcXKEMsQ==:17 a=aatUQebYAAAA:8 a=rt9fHxs5rGgGI8XyeLQA:9 a=u9KkB1HKLPl6r43OOuIA:7 a=AJAAz9zk7vd98phR2PE0T3eqjIMA:4 a=wPNLvfGTeEIA:10 a=rBKJJ2Jc0C4A:10 a=bURaG8XmhAi4FTBd:21 a=lOOtqiMLxKmJ6CIv:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: "freebsd-fs@freebsd.org" Subject: Re: Should gmirrored gjournal provider have auto-synchronization? 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, 08 Oct 2010 03:22:17 -0000 On 2010-10-07 3:21 PM, Hywel Mallett wrote: > On 7 Oct 2010, at 08:35, Carl wrote: >> Then, should I be enabling or disabling auto-synchronization for >> the mirrored journal provider partition? It is clear to me that it >> should be disabled for the mirrored data provider partition because >> the journaling will ensure data consistency, but is the content of >> the journal provider itself guaranteed consistent under all >> circumstances? > > That's an interesting question. I think you're correct that you > should be able to disable auto-sync for the data slice, provided that > gmirror returns a write as succeeded only when it has been written to > both parts of the mirror. If not, then you could theoretically end up > with a situation where data has only been written to one half of the > mirror, but the write has been returned as successful, and gjournal > won't re-write the data, which would leave you with an unsynchronized > mirror. With gmirror, when you say "guaranteed consistent", you may > need to qualify that more. gmirror guarantees that a collection of > writes either happens in it's entirety, or not at all. My admittedly limited understanding of gmirror is that it makes no such guarantee. I think it is gjournal that guarantees the consistency of the file system that sits on top of it, not gmirror, and this would be true even if there were no gmirror below it. The gjournal(8) man page tells us that when gmirror does exist below gjournal that gmirror's auto-sync need not be enabled because of that consistency guarantee. But again, we've been given a guarantee that the file system is consistent, but no where (that I can find) are we told whether the design of the journal itself is such that it too is guaranteed consistent. My best guess is that a separate journal provider is inherently guaranteed consistent. My reasoning is that when it is not separate (ie. data and journal share same provider) we are told that we can disable auto-sync if gmirror is below it, which seems like bad advice if the consistency guarantee applies only to the data and not the journal. It would nonetheless be nice to have a confirmation that auto-synchronization can be disabled safely for a separate journal provider. Carl / K0802647