The old code used mf->mf_max for correcting the file size, but that
was wrong for multiple writes in flight.
A really correct solution would have to remember all in-flight writes
and compute their minimum IO position. Since that would be too
costly, we just use the old size before any writes have started.
This might be too conservative for extremely high load patterns
(possible starvation problem). For now, take this and check whether
we really need higher effort.
It appears that concurrent reads and writes on AIO seem to
result in inconsistent reads in some very rare cases, due to
races. Sometimes, the inode claims that the file has been already
appended by a write operation, but the data has not actually hit
the page cache, such that a concurrent read gets NULL blocks.
This is a workaround by "misusing" the mapfree infrastructure.
It depends on uniqueness of file names, which is not the right thing
to do.
Best fix would be in the kernel.
