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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 23 2001 - 21:00:27 EST