Re: [RFC] Early flush (was: spindown)

[Daniel Phillips <phillips@bonn-fries.net>]

On Wednesday 20 June 2001 06:39, Richard Gooch wrote:
> Daniel Phillips writes:
> > I never realized how much I didn't like the good old 5 second delay
> > between saving an edit and actually getting it written to disk until
> > it went away.  Now the question is, did I lose any performance in
> > doing that.  What I wrote in the previous email turned out to be
> > pretty accurate, so I'll just quote it
>
> Starting I/O immediately if there is no load sounds nice. However,
> what about the other case, when the disc is already spun down (and
> hence there's no I/O load either)? I want the system to avoid doing
> writes while the disc is spun down. I'm quite happy for the system to
> accumulate dirtied pages/buffers, reclaiming clean pages as needed,
> until it absolutely has to start writing out (or I call sync(2)).

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.

You know about this project no doubt:

   http://noflushd.sourceforge.net/

This is really complementary to what I did.  Lightweight is not really a good 
way to describe it though, the tar is almost 10,000 lines long.  There is 
probably a clever thing to do at the kernel level to shorten that up.

There's one thing I think I can help fix up while I'm working in here, this 
complaint: 

    Reiserfs journaling bypasses the kernel's delayed write mechanisms and    
    writes straight to disk.

We need to address the reasons why such filesystems have to bypass kupdate.  
This touches on how sync and fsync work, updating supers, flushing the inode 
cache etc, but with Al Viro's superblock work merged now we could start 
thinking about it.

> Right now I hack that by setting bdflush parameters to 5 minutes. But
> that's not ideal either.

Yes, that still works with my patch.  The noflushd user space daemon works by 
turning off kupdate (set update time to 0).

--
Daniel