From owner-freebsd-current Fri Oct 2 13:27:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA00221 for freebsd-current-outgoing; Fri, 2 Oct 1998 13:27:44 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA00191 for ; Fri, 2 Oct 1998 13:27:21 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id OAA17722; Fri, 2 Oct 1998 14:26:56 -0600 (MDT) Message-Id: <199810022026.OAA17722@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer cc: "Justin T. Gibbs" , Don Lewis , current@FreeBSD.ORG Subject: Re: Softupdates, filesystem safety and SCSI disk write caching In-reply-to: Your message of "Fri, 02 Oct 1998 13:12:57 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Oct 1998 14:20:26 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Of course.. All I'm saying is that It is a prerequisite that we should >document somewhere, that "Softupdates assumes that completion signals the >arrival of the data into STABLE storage, e.g. magnetic recording." If we tagged meta-data buffers appropriately, we could specificly inhibit write-caching those transactions. I would expect this to give you the semantics soft-updates expects while still allowing the disk to write cache data blocks. So, if you have a power failure, the file-system meta-data would be consistent, but some files might have stale data blocks. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message