From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Date: Fri, 9 Jan 2009 13:38:50 +0100 From: Sape Mullender Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-qfthvlyaugezbcbbikmdzybyuf" Subject: Re: [9fans] venti Topicbox-Message-UUID: 7de020ae-ead4-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-qfthvlyaugezbcbbikmdzybyuf Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yes, but even if one venti always leaves the store in a consistent state, running two may still cause them to wite differemt things to the same place on disk and this is likely to result in havoc. Sape --upas-qfthvlyaugezbcbbikmdzybyuf Content-Type: message/rfc822 Content-Disposition: inline Received: from gouda.swtch.com ([67.207.142.3]) by plan9; Fri Jan 9 07:19:54 EST 2009 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from <9fans-bounces@9fans.net>) id 1LLGJy-0008Fk-UT; Fri, 09 Jan 2009 12:18:39 +0000 Received: from smarthost02.mail.zen.net.uk ([212.23.3.141]) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from ) id 1LLGJx-0008Ff-DX for 9fans@9fans.net; Fri, 09 Jan 2009 12:18:37 +0000 Received: from [82.71.34.244] (helo=zen.hamnavoe.com) by smarthost02.mail.zen.net.uk with esmtp (Exim 4.63) (envelope-from ) id 1LLGJw-00049v-5D for 9fans@9fans.net; Fri, 09 Jan 2009 12:18:36 +0000 Message-ID: To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Fri, 9 Jan 2009 12:18:35 +0000 In-Reply-To: <10bfefea89ce073c1640dd187f77ec79@plan9.cs.bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-Smarthost02-IP: [82.71.34.244] Subject: Re: [9fans] venti X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+9fans-local=plan9.bell-labs.com@9fans.net > Hmm. Running two ventis on the same data is, of course, bad. It's also > something I haven't seen happen before. I think it may have happened to me. Recently I had a "missing score" error when I was looking for something in my dump fs. To assess the damage I did a 'venti/copy -r' to a spare server, which told me 13 pointers had to be rewritten. I do sometimes get errors like this from my fossil server: could not write super block; waiting 10 seconds blistAlloc: called on clean block but I've been assuming they are benign. Am I wrong? My understanding of fossil is that venti writes are ordered such that the store should not be left in an inconsistent state even after a sudden shutdown. If that's the case, I'm guessing the most likely cause of corruption was a careless experiment with venti when there was already one running. --upas-qfthvlyaugezbcbbikmdzybyuf--