From owner-freebsd-stable@FreeBSD.ORG Fri Apr 18 14:08:07 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 78E7337B40B; Fri, 18 Apr 2003 14:08:07 -0700 (PDT) Received: from mail.tel.fer.hr (zg07-053.dialin.iskon.hr [213.191.150.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A04F43FE9; Fri, 18 Apr 2003 14:08:05 -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 h3IL6CxI000936; Fri, 18 Apr 2003 23:06:16 +0200 (CEST) (envelope-from zec@tel.fer.hr) From: Marko Zec To: Terry Lambert Date: Fri, 18 Apr 2003 23:07:53 +0200 User-Agent: KMail/1.5 References: <200304162310.aa96829@salmon.maths.tcd.ie> <200304180245.53107.zec@tel.fer.hr> <3E9F4FE4.9B8567DC@mindspring.com> In-Reply-To: <3E9F4FE4.9B8567DC@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304182307.53890.zec@tel.fer.hr> cc: freebsd-fs@freebsd.org 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:08:07 -0000 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. 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? > > Under what circumstances you you find that delaying fsync() > helps you? What program are you running that calls fsync()? The vi editor, pretty much every e-mail client, and so on... > Even if you don't use it for a > statistical check, it will check you on the number of times > fsync() (and sync()) get called by someone. If it's a small > number, you need to fix the bogus program, rather than hack > the kernel. 8-). No, those programs are not bogus, and neither is the kernel. I just want to have a method to keep the damn disk spinned down, that's all. Marko