Commit 06bd3c36a733ac27962fea7d6f47168841376824 "ext4: fix data exposure after
a crash" regressed WAL times of pgioperf-bench on ext3 filesystem ~100x for
balada.arch.suse.de. COMMIT times regressed ~10x.

The benchmark is doing random 8k writes into a large datafile (2*memsize)
calling fsync after 800MB written and cycling 8k writes into wal file, fsyncing
it every 5 writes. In parallel there are lots of random reads going on.

The regression is caused by the fact that before above mentioned commit
datafile inode was always attached to transaction in ext4_write_end() and thus
random writes were continuously trickled to the filesystem using WRITE_SYNC
writes. After the patch this does not happen and writes are written back by
flush worker using async writes. Likely these get starved by parallel readers
and as a result WAL writer gets stuck in write(2) for extended periods of time.