From owner-freebsd-stable@FreeBSD.ORG Sat Apr 19 15:56:46 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 AA05537B401 for ; Sat, 19 Apr 2003 15:56:46 -0700 (PDT) Received: from mail.tel.fer.hr (zg04-084.dialin.iskon.hr [213.191.137.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBD4443F75 for ; Sat, 19 Apr 2003 15:56:43 -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 h3JMshxI001030; Sun, 20 Apr 2003 00:54:47 +0200 (CEST) (envelope-from zec@tel.fer.hr) From: Marko Zec To: Chris Pressey , freebsd-stable@freebsd.org Date: Sun, 20 Apr 2003 00:56:24 +0200 User-Agent: KMail/1.5 References: <3E976EBD.C3E66EF8@tel.fer.hr> <3EA1B72D.B8B96268@mindspring.com> <20030419172756.17aaf627.cpressey@catseye.mb.ca> In-Reply-To: <20030419172756.17aaf627.cpressey@catseye.mb.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304200056.24781.zec@tel.fer.hr> 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: Sat, 19 Apr 2003 22:56:46 -0000 On Sunday 20 April 2003 00:27, Chris Pressey wrote: > A simple comment to this effect (like 'all writes are delayed, so they > go out to disk in a burst which can suspend the machine for a long > time') next to the option in question would serve the same purpose. I agree 100%. However, note that write bursts will typically occur combined with disk spinups. As it takes one to two seconds first to spin up the disk, the additional couple of _miliseconds_ will be completely unnoticable in almost all cases. > Isn't the danger, basically, that a computer running FreeBSD with this > patch could potentially: > - accumulate a LOT of future writes to be done all at once Yes, it could accumulate a lot of writes to be done all at once - that is the whole purpose of the patch. No, it will not accumulate more dirty buffers than the standard code, as the syncer will start writing the buffers to the disk once the resources become scarce. > - exhaust its resources when actually synchronizing those writes No (I guess :) > - panic Not a single panic until now. > Terry: try to keep some perspective. > Marko: clearly mark the patch 'experimental'. Well, I'm affraid after this debate with Terry I can only mark the patch as "dead" :( Marko