On Wed, Jun 20, 2001 at 10:12:38AM -0600, Richard Gooch wrote:> Daniel Phillips writes:> > I'd like that too, but what about sync writes? As things stand now,> > there is no option but to spin the disk back up. To get around this> > we'd have to change the basic behavior of the block device and> > that's doable, but it's an entirely different proposition than the> > little patch above.> > I don't care as much about sync writes. They don't seem to happen very> often on my boxes.

syslog and some editors are the most common users of sync writes. vim, e.g.,per default keeps fsync()ing its swapfile. Tweaking the configuration ofthese apps, this can be prevented fairly easy though. Changing sync semanticsfor this matter on the other hand seems pretty awkward to me. I'd expect anapplication calling fsync() to have good reason for having its data flushedto disk _now_, no matter what state the disk happens to be in. If it hasn't,fix the app, not the kernel.

> > You know about this project no doubt:> > > > http://noflushd.sourceforge.net/> > Only vaguely. It's huge. Over 2300 lines of C code and >560 lines in> .h files! As you say, not really lightweight. There must be a better> way.

noflushd would benefit a lot from being able to set bdflush parameters perdevice or per disk. So I'm really eager to see what Daniel comes up with.Currently, we can only turn kupdate either on or off as a whole, which meansthat noflushd implements a crude replacement for the benefit of multi-disksetups. A lot of the cruft stems from there.

> Also, I suspect (without having looked at the code) that it> doesn't handle memory pressure well. Things may get nasty when we run> low on free pages.

It doesn't handle memory pressure at all. It doesn't have to. noflushd onlymesses with kupdate{,d} but leaves bdflush (formerly known as kflushd) alone.If memory gets tight, bdflush starts writing out dirty buffers, which makes thedisk spin up, and we're back to normal.