xfs/182: fix spurious direct write failure

xfs/182: fix spurious direct write failure

This test has some weird behavior that causes regressions when fsdax and
reflink are enabled.  The goal of this test is to set a cow extent size
hint, perform some random directio writes, perform a directio rewrite of
the entire file, and make sure that the file content (and extent count)
are sane afterwards.

Most of the time, the random directio writes will never touch the
8388609th byte, though if they do randomly select that EOF block, they'd
end up extending the file by $real_blksz bytes and causing spurious test
failures.

Then, the rewrite does this:

pwrite -S 0x63 -b $real_blksz 0 $((filesize + 1))

Note that we previously set filesize=8388608, which means that we're
asking for a series of direct writes that fill the first 8388608 bytes
with 'c'.  The last write in the series becomes a single byte direct
write.  For regular file access mode, this last write will fail with
EINVAL, since block devices do not support byte granularity writes and
XFS does not fall back to the pagecache for unaligned direct wites.
Hence we never wrote the 8388609th byte of the file.

However, fsdax *does* allow byte-granularity direct writes, which means
that the single-byte write succeeds.  There is no EINVAL return code,
and the 8388609th byte of the file is now 'c' instead of 'a'.  As a
result, the md5 of file2 is different.

Since fsdax+reflink is the newcomer, amend the direct writes in this
test so that they always end at the 8388608th byte, since we were never
really testing that last byte anyway.  This makes the test behavior
consistent across both access modes.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Xiao Yang <yangx.jy@fujitsu.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>