Date: Sat, 19 Apr 2003 00:03:20 -0700 From: David Schultz <das@FreeBSD.org> To: Marko Zec <zec@tel.fer.hr> Cc: freebsd-stable@FreeBSD.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <20030419070320.GA14034@HAL9000.homeunix.com> In-Reply-To: <200304182243.05739.zec@tel.fer.hr> References: <3E976EBD.C3E66EF8@tel.fer.hr> <3E9E93D8.EB16ED42@tel.fer.hr> <20030418071329.GA9125@HAL9000.homeunix.com> <200304182243.05739.zec@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030419070320.GA14034>