From owner-freebsd-current Fri Oct 2 13:16:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA28408 for freebsd-current-outgoing; Fri, 2 Oct 1998 13:16:28 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA28402 for ; Fri, 2 Oct 1998 13:16:26 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA05132; Fri, 2 Oct 1998 13:13:02 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdGL5123; Fri Oct 2 20:13:00 1998 Date: Fri, 2 Oct 1998 13:12:57 -0700 (PDT) From: Julian Elischer To: "Justin T. Gibbs" cc: Don Lewis , current@FreeBSD.ORG Subject: Re: Softupdates, filesystem safety and SCSI disk write caching In-Reply-To: <199810021953.NAA12817@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 2 Oct 1998, Justin T. Gibbs wrote: > >write caching can screw soft updates if there is any > >major re-ordering of the data written. > > Only if you lose power or have a buggy device. Go read the SCSI spec on > write caching. I'm aware of this.. All I am doing is stating the assumptions made in soft-updates... which are: The softupdates code will 'release' a requested transaction to be written to the disk when all prerequisite operations have been reported as complete. Softupdates is designed to leave the disk in a stable state after a powerdown. If the disk however reports an operation as 'complete' when it is in fact not on stable storage, then softupdates may release an operation to be written to disk that depends upon something that is not yet written to the medium. If the new operation "overtakes" the old operation in cache, and makes it to the medium first, then the disk is in an inconsistent state until the older IO is completed. This is one reason that we disable Write caching on IDE drives running softupdates. A power failure at the moment of inconsistency will leave the disk in that state, which is what softupdates is trying to avoid. > > With tags it doesn't matter if they are re-ordered, as long as they > > are not acknowledged until they are on the platter. By which I mean, Softupdates doesn't care if multiple operations passed to the drive are re-orderd within the drive, as they by definition will have no interdependencies. (Or Softupdates would not have passed them to the drive). Softupdates however must not be allowed to advance the dependency state machine for it's data before the data is really safe. > > Tagged transactions may "complete" in a non-FIFO order. "Complete" either > means data transfered into the cache or data safely on the media depending > on whether the cache is enabled. 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." > Re-ordered writes are allowed, but, only such that it maintains > read/write coherency. This is with the restrictive ordering semantics > that drives usually ship with by default. You can turn on "re-order at > will" through a mode page. > > Justin > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message