From owner-freebsd-fs@FreeBSD.ORG Fri Apr 18 14:21:33 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 BDD4B37B401; Fri, 18 Apr 2003 14:21:33 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2300C43F85; Fri, 18 Apr 2003 14:21:33 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0240.cvx22-bradley.dialup.earthlink.net ([209.179.198.240] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 196dIY-0005ad-00; Fri, 18 Apr 2003 14:21:31 -0700 Message-ID: <3EA06C07.A34F1C31@mindspring.com> Date: Fri, 18 Apr 2003 14:20:07 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marko Zec References: <3E976EBD.C3E66EF8@tel.fer.hr> <3E9E93D8.EB16ED42@tel.fer.hr> <200304182243.05739.zec@tel.fer.hr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a435745805e1197074fb358af05677c83f667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c cc: freebsd-fs@FreeBSD.org cc: David Schultz cc: freebsd-stable@FreeBSD.org 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 21:21:34 -0000 Marko Zec wrote: > On Friday 18 April 2003 09:13, David Schultz wrote: > > Your code bumps rushjob up by the arbitrary value 32, which is > > rather large. Doing so is going to throw things out of whack. > > Which things and how? > > > What you would probably want to do is leave rushjob alone. If it > > ever becomes nonzero, the syncer should wake up and start writing > > again. > > Sure, that's precisely why I increment rushjob - to instruct the syncer to > start synching when I want it to. What's wrong with that? Touching rushjob is probably not a good idea. The main technical (not philosophical) problem with the patch as it sits is that you can cause the soft updates wheel to wrap around. Then when you write things out, they write out of order. The purpose of the wheel is to allow placing of operations at some relative offset in the future to an outstanding operation, to ensure ordering. No matter what else you do, you can not allow the wheel to "wrap". Because the offsets are "future relative", that means that you have to flush at some number of wheel entries equal to: wrap_boundary - the_largest_potential_future_offset - 1. Making the wheel bigger is probably acceptable, but then you will exacerbate the memory problem that rushjob was invented to resolve (please do a "cvs log" and look at the checkin comments; I still believe it was "dillon" who made the change). -- Terry