From owner-freebsd-stable@FreeBSD.ORG Fri Jun 17 19:12:01 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B152E16A41C for ; Fri, 17 Jun 2005 19:12:01 +0000 (GMT) (envelope-from steve@sohara.org) Received: from sohara.org (sohara.org [192.220.64.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97D7743D1F for ; Fri, 17 Jun 2005 19:12:01 +0000 (GMT) (envelope-from steve@sohara.org) Received: (qmail 24194 invoked by uid 16563); 17 Jun 2005 19:12:00 -0000 Received: from unknown (HELO df1) ([80.7.161.165]) (envelope-sender ) by 192.220.64.179 (qmail-ldap-1.03) with SMTP for ; 17 Jun 2005 19:12:00 -0000 Date: Fri, 17 Jun 2005 20:11:58 +0100 From: Steve O'Hara-Smith To: David Sze Message-Id: <20050617201158.00ec8646.steve@sohara.org> In-Reply-To: <20050617185726.GD94284@mail.distrust.net> References: <20050617155938.GB94284@mail.distrust.net> <200506171620.j5HGKxwW042819@drjekyll.mkbuelow.net> <20050617185726.GD94284@mail.distrust.net> Organization: Steve O'Hara-Smith X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, nalists@scls.lib.wi.us, uzi@bmby.com, mkb@incubus.de Subject: Re: FreeBSD MySQL still WAY slower than Linux X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 19:12:01 -0000 On Fri, 17 Jun 2005 13:57:26 -0500 David Sze wrote: > I'm not sure filesystem consistency alone is "good enough". Say your > bank's database crashes right after you make a deposit. When it comes > back up it's consistent, but only up to 5 minutes before the crash due > to the async mount. > > For this type of application, something in the system has to be keeping > a "journal" on a sync mount in order for recovery to be both consistent > and correct. For that critical an application the transaction should be stored in multiple physically separated locations and confirmed by the two faced kermit\w\w\w two phase commit protocol. Said implementation had better have the correct disaster restart protocol implemented too. -- C:>WIN | Directable Mirror Arrays The computer obeys and wins. | A better way to focus the sun You lose and Bill collects. | licences available see | http://www.sohara.org/