From owner-freebsd-stable@FreeBSD.ORG Fri Apr 18 14:49:13 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 EBB3937B404; Fri, 18 Apr 2003 14:49:12 -0700 (PDT) Received: from mail.tel.fer.hr (zg06-176.dialin.iskon.hr [213.191.148.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id E960443FB1; Fri, 18 Apr 2003 14:49:10 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from marko-tp (marko@[192.168.201.107]) by mail.tel.fer.hr (8.12.6/8.12.6) with ESMTP id h3ILlGxI000941; Fri, 18 Apr 2003 23:47:21 +0200 (CEST) (envelope-from zec@tel.fer.hr) From: Marko Zec To: Terry Lambert Date: Fri, 18 Apr 2003 23:48:58 +0200 User-Agent: KMail/1.5 References: <3E976EBD.C3E66EF8@tel.fer.hr> <200304182243.05739.zec@tel.fer.hr> <3EA06C07.A34F1C31@mindspring.com> In-Reply-To: <3EA06C07.A34F1C31@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304182348.58356.zec@tel.fer.hr> 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-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 21:49:13 -0000 On Friday 18 April 2003 23:20, Terry Lambert wrote: > > 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. No, that just cannot happen. You are probably confusing rushjob with syncer_delayno, which gets reset to 0 each time it reaches the value of syncer_maxdelay. The rushjob variable simply tells the syncer how many times it should iterate _sequentially_ through the softupdates queues before getting to sleep on lbolt. > > Then when you write things out, they write out of order. Uhh.. NO! > 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. True. And this has not changed with my patch. > 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). Where from did you get the idea I'm making the wheel bigger? The size of the softupdates "wheel" is determined by the value of syncer_maxdelay, which not only I haven't touched at all, but is also completely unrelated to the rushjob variable. If it is of any relevance for this discussion, I want to add that I've been running my system with extended delaying all the time for the last two weeks (even when on AC power). I have had absolutely no problems nor have lost a single bit of data, even during the most stresfull tests such as untarring of huge archives, or making the kernel etc. Not to mention this is also my primary and "production" machine, with all my e-mail on it etc. Marko