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:
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
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 firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/