From owner-freebsd-hackers Mon Sep 13 23:51:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.mixx.net (hermes.mixx.net [194.152.58.71]) by hub.freebsd.org (Postfix) with ESMTP id D783D14DD7 for ; Mon, 13 Sep 1999 23:51:19 -0700 (PDT) (envelope-from graichen@innominate.de) Received: from innominate.de (gatekeeper.innominate.de [212.5.16.129]) by hermes.mixx.net (8.9.3/8.9.3) with SMTP id IAA19145 for ; Tue, 14 Sep 1999 08:51:18 +0200 Received: (qmail 15420 invoked from network); 14 Sep 1999 06:49:46 -0000 Received: from cello.innominate.local (192.168.0.13) by lingo01.innominate.local with SMTP; 14 Sep 1999 06:49:46 -0000 Received: from localhost (graichen@localhost) by cello.innominate.local (8.9.3/8.9.3) with ESMTP id IAA03358 for ; Tue, 14 Sep 1999 08:51:17 +0200 (CEST) (envelope-from graichen@innominate.de) X-Authentication-Warning: cello.innominate.local: graichen owned process doing -bs Date: Tue, 14 Sep 1999 08:51:16 +0200 (CEST) From: Thomas Graichen X-Sender: graichen@cello.innominate.local To: hackers@FreeBSD.org Subject: SOFTUPDATES and fsck Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hello ... maybe this belongs more to fs than to hackers - but maybe this is the correct place here for it ... i've just read the soft updates paper from: http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/ at which the soft updates README's in the FreeBSD tree point and ran across the following lines in the section 5.1 "file system recovery": "With the conventional implementation, the fsck utility must be run on a file system before it can be mounted after any system failure. By guarateeing that the on-disk metadata can always be used safely (except when media corruption destroys live metadata), our soft updates im- plementation lifts this requirement. A file system can be safely mounted and used immedeately after most system failures, but may contain several inconsistencies: * unused blocks may not appear in the free space maps * inode link counts may exceed the numer of associated directory entries * unreferenced inodes may not appear in the free inode maps One can run the fsck utility on the filesystem, when convenient, to reclaim unreferenced ressources and correct link counts. ..." at another point it is mentioned that it should be doable to write an fsck tool which can do those corrections in background while the filesystem is mountet read/write ... now my question: how much of this applies to the soft updates im- plementation in FreeBSD ? - might this eventually open the door to an fsck free bootup after a system crash without having to write a journaled filesystem for FreeBSD ? - i think this is one point which gets more and more important on systems with several 100 gb disk space and thus enormous fsck times after a failure can anyone - who is deep in the details of the FreeBSD soft updates implementation (julian, matt, kirk) give some comments on this ? a lot of thanks in advance t -- graichen@innominate.de innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message