From owner-freebsd-stable@FreeBSD.ORG Fri Jun 17 16:20:47 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 7701E16A41C for ; Fri, 17 Jun 2005 16:20:47 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35D1B43D4C for ; Fri, 17 Jun 2005 16:20:47 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (p54AAEB90.dip.t-dialin.net [84.170.235.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 9AA342F054; Fri, 17 Jun 2005 18:23:38 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j5HGKxwW042819; Fri, 17 Jun 2005 18:20:59 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Message-Id: <200506171620.j5HGKxwW042819@drjekyll.mkbuelow.net> From: Matthias Buelow To: David Sze In-Reply-To: Message from David Sze of "Fri, 17 Jun 2005 10:59:38 CDT." <20050617155938.GB94284@mail.distrust.net> X-Mailer: MH-E 7.84; nmh 1.0.4; XEmacs 21.4 (patch 17) Date: Fri, 17 Jun 2005 18:20:59 +0200 Sender: mkb@mkbuelow.net Cc: freebsd-stable@freebsd.org, Greg Barniskis , uzi@bmby.com, Matthias Buelow 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 16:20:47 -0000 David Sze writes: >CentOS uses ext3 by default. How does having a journal help if the >journal is stored on the same async filesystem? Unless the journal >writes are guaranteed sync. The journal guarantees that the filesystem will always be consistent. If a journal entry doesn't make it to disk, the operation has never happened; and the journal entry won't get removed, until the metadata update has been performed. So the worst thing that could happen is, that the same operation will be performed twice, once normally, and once at log replay on reboot. This is not an issue, since such metadata operations (delete file from directory, write a value into superblock, etc.) are usually idempotent. That's the basic function of all journalled filesystems, and that's why you don't need to run fsck on them. You don't need to write the journal synchronously, you can do these things in groups. The softupdates mechanism does something similar; only it doesn't maintain an on-disk journal, and hence needs fsck after boot to fix up the free block bitmaps and stuff (basically performing a garbage collection on the filesystem, which, unfortunately, is pretty slow). mkb.