From owner-freebsd-stable@FreeBSD.ORG Sat Apr 19 00:03:27 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 CBDD037B401; Sat, 19 Apr 2003 00:03:27 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15DA743FDF; Sat, 19 Apr 2003 00:03:27 -0700 (PDT) (envelope-from das@FreeBSD.org) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h3J73P9E014134; Sat, 19 Apr 2003 00:03:25 -0700 (PDT) (envelope-from das@FreeBSD.org) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h3J73K2o014133; Sat, 19 Apr 2003 00:03:20 -0700 (PDT) (envelope-from das@FreeBSD.org) Date: Sat, 19 Apr 2003 00:03:20 -0700 From: David Schultz To: Marko Zec Message-ID: <20030419070320.GA14034@HAL9000.homeunix.com> Mail-Followup-To: Marko Zec , freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org References: <3E976EBD.C3E66EF8@tel.fer.hr> <3E9E93D8.EB16ED42@tel.fer.hr> <20030418071329.GA9125@HAL9000.homeunix.com> <200304182243.05739.zec@tel.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <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: Sat, 19 Apr 2003 07:03:28 -0000 On Fri, Apr 18, 2003, Marko Zec wrote: > > 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 Look at -CURRENT. > > 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? My complaint was simply that you're incrementing rushjob by some number you pulled out of a hat, namely 32. This causes the syncer to spin around 32 times every time someone calls sync(), and most of the time, it won't have anything to do. Moreover, in -CURRENT, you can lead the system to believe that resources are scarcer than they really are. Look at what request_cleanup() does when speedup_syncer() fails, for instance. > > 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? You seem to be overthinking this. On a relatively quiescent laptop, all you have to do is have the drives spin down and suspend the operation of the syncer as long as no processes are blocked on I/O. If this results in too many dirty buffers, the system will automatically notice this and kick the syncer. You don't need to step in and kick the syncer 32 times or disable fsync() in order to get reasonable benefits without breaking things. This simple approach can easily be refined later if need be. > > 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. It's the same principle. For flash, you want to limit the number of writes since you only get a finite number of them. For laptops, you want to limit the number of writes because keeping your drive spinning drains the battery. In both cases, you can solve the problem by using a memory filesystem for things like cron that write frequently.