Skip site navigation (1)Skip section navigation (2)
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>