From owner-freebsd-fs@FreeBSD.ORG Thu Feb 10 03:01:21 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 499D216A4CE for ; Thu, 10 Feb 2005 03:01:21 +0000 (GMT) Received: from hosea.tallye.com (joel.tallye.com [216.99.199.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26B2D43D41 for ; Thu, 10 Feb 2005 03:01:20 +0000 (GMT) (envelope-from lorenl@alzatex.com) Received: from hosea.tallye.com (hosea.tallye.com [127.0.0.1]) by hosea.tallye.com (8.12.8/8.12.10) with ESMTP id j1A31JGf030061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Feb 2005 19:01:19 -0800 Received: (from sttng359@localhost) by hosea.tallye.com (8.12.8/8.12.10/Submit) id j1A31JHs030059 for freebsd-fs@freebsd.org; Wed, 9 Feb 2005 19:01:19 -0800 X-Authentication-Warning: hosea.tallye.com: sttng359 set sender to lorenl@alzatex.com using -f Date: Wed, 9 Feb 2005 19:01:19 -0800 From: "Loren M. Lang" To: freebsd-fs@freebsd.org Message-ID: <20050210030119.GD29396@alzatex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-GPG-Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc X-GPG-Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C Subject: Journalling FS and Soft Updates comparision X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 03:01:21 -0000 Traditionally, filesystems have been designed with the idea that the data will always be written to disk safely and not much effort was put into making then Journalling Filesystems and Soft Updates are two different techniques designed to solve the problem of keeping data consistent even in the case of a major interruption like a power blackout. Both work solely on the meta data, not the real data. This means increasing a file's size is protected, but not neccessarily the data that's being written. (Does this also mean that the data will be written to free space before the file size is increased so extraneous data won't be left in the file?) Journally works be recording in a special place on the hard drive called the journal every meta data change that it is about to execute before it does it, then it updates all the meta data and finally marks the journal completed. Soft updates are simply a way to order meta data so that it happens in a safe order. An example is moving file a from directory x to directory y would first delete file a from dir x, then add it to dir y. If a crash happens in the middle, then the data becomes lost right? Now this shouldn't be a big deal since it's harmless to anything else, just some free space is eaten up. Since all meta data updates have this same kind of harmless behavior, that why fsck can be done in the background now instead of foreground. Now comparing the two, perfomance wise journalling has an advantage since every group of meta data updates that are written to the journal at the same time can be reordered to optimize the disk performance. The disk head just has to move across the disk in order instead of seeking back and forth. Now this performance is usually lost because the journal is constantly needing to be updated and it probably lies in one small ares of the disk. The other benefit of the journal is very quick fsck times since all it has do to it see what the journal was updating and make sure it all completed. Soft updates still require a full fsck, but since it can be done in the background unlike journalling, it mean even faster startup time, but more cpu and i/o time spent on it. Now if the journal of a journalling fs could be kept somewhere else, say, in some kind of nvram, then journalling might be overall more efficient as far as disk i/o and cpu time than soft updates. I'm mainly just trying to get an understanding of these two techniques, not neccessarily saying one is better. In the real world, it's probably very dependent on many other things like lot of random access vs. sequential, many files and file ops per seconds, vs. mostly read-only with noatime set, etc. -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C