Solving the ext3 latency problem

"data=ordered" provides nearly ideal recovery semantics, but it is stronger
than necessary to provide reasonable recovery behavior in most cases. A
strict interpretation of data=ordered means committing dirty data to disk
before any meta data updates. That means that calling fsync on any file
with dirty buffers is equivalent in cost to calling fsync on every file
with dirty buffers in the filesystem.

Since data=ordered tends to interfere with getting real work done without
stalling the question is what kinds of relaxations can be made without
imperiling the integrity of your filesystem. "data=writeback" is the no
holds barred assume your system is never going to crash tough luck for any
recently touched files but you probably won't have to spend hours waiting
for fsck sort of preference.

Fortunately, there is a lot of room for reasonable, safer relaxations
between data=ordered and data=writeback. data=guarded is one such option
that allows preliminary meta data commits for unrelated files to proceed
with a smaller file size corresponding to the file data that has actually
been written to disk. That works really well as long as you are not trying
to replace an existing file. If you are doing rename replacements the same
problem comes back to haunt you in a way that data=guarded doesn't solve.
(Rename undo would...)