From owner-freebsd-stable@FreeBSD.ORG Fri Apr 18 13:43:18 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 96CF237B401; Fri, 18 Apr 2003 13:43:18 -0700 (PDT) Received: from mail.tel.fer.hr (zg04-042.dialin.iskon.hr [213.191.137.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF01243F85; Fri, 18 Apr 2003 13:43:15 -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 h3IKfPxI000931; Fri, 18 Apr 2003 22:41:26 +0200 (CEST) (envelope-from zec@tel.fer.hr) From: Marko Zec To: David Schultz Date: Fri, 18 Apr 2003 22:43:05 +0200 User-Agent: KMail/1.5 References: <3E976EBD.C3E66EF8@tel.fer.hr> <3E9E93D8.EB16ED42@tel.fer.hr> <20030418071329.GA9125@HAL9000.homeunix.com> In-Reply-To: <20030418071329.GA9125@HAL9000.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304182243.05739.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 20:43:18 -0000 On Friday 18 April 2003 09:13, David Schultz wrote: > When the system is low on memory or has reached a related limit, > it tries to sync data to disk faster by slowly increasing the > value of rushjob until the situation improves. If the syncer is > able to keep up, it will process data faster and pull rushjob back > down to zero. True. > If rushjob gets too high (half the maximum sync > delay, usually 15), the system resorts to other measures. Which measures, and in which cases? The only two chunks of code in the entire -stable kernel that probe the value of rushjob (indirectly through invoking speedup_syncer() ) are newdirrem() and inodedep_lookup() in ufs/ffs/ffs_softdep.c. Neither of these two will either corrupt a single bit of data or crash the system if rushjob gets higher than max syncdelay / 2. > 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? > If you would like to write the data out more quickly > whenever the disks start up so you can make them spin down again, > look at softdep_request_cleanup() in -CURRENT. > > But really, even getting fsync() to do *remotely* the right thing > (i.e. correct ordering but no guarantee of writing data to stable > storage when in power save mode) is going to be *really*hard*. > Warner has a much better suggestion. If I'm not mistaking Warner was talking about using memory based FS and periodically synching it to a flash based device. Such a concept is perfectly sane for appliances using solid state disks, however I don't see how it can be applied to a typical laptop. Marko