From owner-freebsd-stable@FreeBSD.ORG Fri Apr 18 11:13:36 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2CF937B401; Fri, 18 Apr 2003 11:13:35 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26CA443FD7; Fri, 18 Apr 2003 11:13:35 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0577.cvx22-bradley.dialup.earthlink.net ([209.179.200.67] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 196aMd-0000Nt-00; Fri, 18 Apr 2003 11:13:32 -0700 Message-ID: <3EA03FF1.280B6810@mindspring.com> Date: Fri, 18 Apr 2003 11:12:01 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Schultz 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> <20030418124914.GA10979@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a491ef9124fa8972c225596c66c40ce4b6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 18:13:36 -0000 David Schultz wrote: > > 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 it sits, the implementation is via a timer that is not under OS control. It would be nice if it used this method, instead, since it would allow anyone who wanted to to implement a "policy", if the default policy bothered them (e.g. do it when the screen saver kicks on, or do it when there haven't been any mouse/keyboard input events for XX seconds, etc. -- you could even hook this to whether the delayed fsync is active or not, which seems a better time for it to be active, anyway). > As for the ATA delayed write feature, I don't believe it will > guarantee consistency. It doesn't. I checked, after voicing my suspions of it. > 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. You can't turn the reordering off, and your example is exactly the "barrier" case I had previously described. 8-). -- Terry