From owner-freebsd-fs@FreeBSD.ORG Fri Apr 18 14:24:56 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 5C79B37B401; Fri, 18 Apr 2003 14:24:56 -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 BD3B543FD7; Fri, 18 Apr 2003 14:24:55 -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 196dLp-00061Q-00; Fri, 18 Apr 2003 14:24:54 -0700 Message-ID: <3EA06CD2.E299D864@mindspring.com> Date: Fri, 18 Apr 2003 14:23:30 -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> <200304180245.53107.zec@tel.fer.hr> <3E9F4FE4.9B8567DC@mindspring.com> <200304182307.53890.zec@tel.fer.hr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4fc7764252737ce9c695e8026c7825103667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c cc: freebsd-fs@freebsd.org 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:24:56 -0000 Marko Zec wrote: > On Friday 18 April 2003 03:07, Terry Lambert wrote: > > No, you are missing my previous point: the check for free space > > should include a check for number of elements *TOTAL* in all slots > > on the soft updates timer wheel. Otherwise it can eat all of > > memory. > > > > The free space check only works in the case that you've done a > > delete and are allocating new space: the case where you are doing > > more and more allocations/opverwrites of data is not handled, and > > can grow to eat all available kernel memory. There was in fact a > > bug, early on, that Matt Dillon worked around that caused it under > > load, and it was in exactly the code you are touching. > > If what you are saying were true, than one could simply crash an _unpached_ > system by doing a lot of FS write operations. No. See the checkin comments for "rushjob". > What my patch does is that it > just temporarily suspends the softupdates "wheels" as you call it. However, > if VM or another ffs subsytem indicates (by increasing the value of rushjob) > that buffers should get flushed more frequently, than my patch will > _immediately_ drop out of the delay loop and allow the syncing to proceed > ASAP. I really do not see what can be wrong with such a concept? No. See last posting: the wheel can not be allowed to "wrap". -- Terry