From owner-freebsd-fs@FreeBSD.ORG Fri Apr 18 05:49:20 2003 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 4C2BE37B401; Fri, 18 Apr 2003 05:49:20 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 949E343F3F; Fri, 18 Apr 2003 05:49:19 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h3ICnG9E011022; Fri, 18 Apr 2003 05:49:16 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h3ICnEHq011021; Fri, 18 Apr 2003 05:49:15 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 18 Apr 2003 05:49:14 -0700 From: David Schultz To: Terry Lambert Message-ID: <20030418124914.GA10979@HAL9000.homeunix.com> Mail-Followup-To: Terry Lambert , Marko Zec , freebsd-fs@freebsd.org, Ian Dowse , freebsd-stable@freebsd.org, Kirk McKusick References: <200304162310.aa96829@salmon.maths.tcd.ie> <3E9E9827.4BB19197@tel.fer.hr> <3E9EDC38.1CE381C6@mindspring.com> <200304172143.26387.zec@tel.fer.hr> <3E9F4413.D294E69E@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9F4413.D294E69E@mindspring.com> cc: freebsd-fs@FreeBSD.ORG cc: freebsd-stable@FreeBSD.ORG cc: Ian Dowse cc: Kirk McKusick Subject: Re: PATCH: Forcible delaying of UFS (soft)updates 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: Fri, 18 Apr 2003 12:49:20 -0000 On Thu, Apr 17, 2003, Terry Lambert wrote: > Marko Zec wrote: > > > You are much better off accumulating requests in the kernel in > > > buffers, and then using the normal write mechanism to push them > > > out to the drive ordered (IMO). > > > > That is precisely what the original OS-controlled delayed synching patch does > > :) > > Yeah, but the spin-down isn't really under OS control, except > as a sort of statistical hysteresis thing. 8-). The OS can know exactly when the disk is spinning if it tells the disk not to timeout all by itself with the IDLE command, and explicitly tells it to IDLE IMMEDIATE at the appropriate time. But being exact about this isn't particularly important. As for the ATA delayed write feature, I don't believe it will guarantee consistency. This is true even if the drive doesn't reorder writes, which it is free to do. Consider a correctness constraint given by the partial ordering of blocks A->B->A. That is, we have to first make a change to block A, then update block B, then make a different change to block A. This is going to be fairly common if a fair number of writes are queued; it happens whenever an editor saves a file using the correct fsync/rename sequence, for instance. The disk will coalesce the two writes to A in its cache and therefore violate the constraint.