> Chris Snook wrote: > > Al Boldi wrote: > > > Greetings! > > > > > > data=ordered mode has proven reliable over the years, and it does this > > > by ordering filedata flushes before metadata flushes. But this > > > sometimes causes contention in the order of a 10x slowdown for certain > > > apps, either due to the misuse of fsync or due to inherent behaviour > > > like db's, as well as inherent starvation issues exposed by the > > > data=ordered mode. > > > > > > data=writeback mode alleviates data=order mode slowdowns, but only works > > > per-mount and is too dangerous to run as a default mode. > > > > > > This RFC proposes to introduce a tunable which allows to disable fsync > > > and changes ordered into writeback writeout on a per-process basis like > > > this: > > > > > > echo 1 > /proc/`pidof process`/softsync > > > > > > > > > Your comments are much welcome! > > > > This is basically a kernel workaround for stupid app behavior. > > Exactly right to some extent, but don't forget the underlying data=ordered > starvation problem, which looks like a genuinely deep problem maybe related > to blockIO. It is a problem with the way how ext3 does fsync (at least that's what we ended up with in that konqueror problem)... It has to flush the current transaction which means that app doing fsync() has to wait till all dirty data of all files on the filesystem are written (if we are in ordered mode). And that takes quite some time... There are possibilities how to avoid that but especially with freshly created files, it's tough and I don't see a way how to do it without some fundamental changes to JBD. Honza -- Jan Kara <jack@xxxxxxx> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
