From owner-freebsd-stable Thu Aug 3 15:20:21 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mail2.uniserve.com (mail2.uniserve.com [204.244.156.10]) by hub.freebsd.org (Postfix) with ESMTP id 8617D37B88B for ; Thu, 3 Aug 2000 15:20:18 -0700 (PDT) (envelope-from tom@uniserve.com) Received: from shell.uniserve.ca ([204.244.186.218]) by mail2.uniserve.com with esmtp (Exim 3.13 #1) id 13KTLS-00046k-00; Thu, 03 Aug 2000 15:20:06 -0700 Date: Thu, 3 Aug 2000 15:20:02 -0700 (PDT) From: Tom X-Sender: tom@shell.uniserve.ca To: Peter Jeremy Cc: Paul Coyne , freebsd-stable@FreeBSD.ORG Subject: Re: Cached versus non cached disk I/O In-Reply-To: <00Aug4.072549est.115835@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 4 Aug 2000, Peter Jeremy wrote: > On Tue, Jul 11, 2000 at 09:06:31PM -0700, Tom wrote: > > It > >should be obvious that write-buffering metadata can cause problems, even > >with softupdates, though softupdates is clearly better than async. > > Not quite. softupdates is actually more robust than a normal FS > mount (and far more robust than async). The softupdates code > controls the ordering of both data and metadata writes to ensure > that the FS on disk is always internally consistent. With a > normal mount, the metadata is mostly internally consistent, but > is not necessarily consistent with the data. Not likely. I personally pushed softupdates over the edge before (see archives). In my case, the amount of unwritten metadata filled up all kernel space. The filesystem was recoverable, but fsck filled up lost+found several times (that should be considered a fsck bug that wasn't possible to expose without softupdates). It was rather messy. > Peter Tom Uniserve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message