From owner-freebsd-stable@FreeBSD.ORG Thu Apr 17 17:18:54 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 A75C037B401; Thu, 17 Apr 2003 17:18:54 -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 DAD4543F75; Thu, 17 Apr 2003 17:18:53 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0101.cvx22-bradley.dialup.earthlink.net ([209.179.198.101] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 196JaU-00052N-00; Thu, 17 Apr 2003 17:18:43 -0700 Message-ID: <3E9F4413.D294E69E@mindspring.com> Date: Thu, 17 Apr 2003 17:17:23 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marko Zec References: <200304162310.aa96829@salmon.maths.tcd.ie> <3E9E9827.4BB19197@tel.fer.hr> <3E9EDC38.1CE381C6@mindspring.com> <200304172143.26387.zec@tel.fer.hr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4a048fd8ed6dd21c47885f8499087e66e3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: freebsd-fs@freebsd.org cc: Ian Dowse cc: freebsd-stable@freebsd.org 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 00:18:55 -0000 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 real problem that people have with the patch is that it is moderately evil, in that the fsync() doesn't block until it has actually sync'ed the data out to the disk, like fsync() is supposed to... and it lets dependent operations keep going. So you break the semantics. I think people would be happier if you just stopped the soft updates sync clock, and then if someone actually fsync()'ed, or the dependency list got too big, it spun up the disk, completed all the I/O quickly, and then spun it down again. > > This is useful, but not enough. You need to actually communicate > > the information above the block I/O layer, to the soft updates. I > > think, effectively, what you actually want to do is to stop the > > soft updates clock > > Hey man, that's exactly what I have done in my patch ("stopping the soft > updates clock" as you call it). On the block I/O layer I'm only checking if > the disk is active or not... Are you sure you have checked out the patch / > code? See above; do that AND preserve the fsync() semantics, and you'll have something (still thinking there's a confusion between fsync() semantics and syncd operation). -- Terry