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