xfs: ensure truncate forces zeroed blocks to disk
authorDave Chinner <dchinner@redhat.com>
Mon, 23 Feb 2015 11:37:08 +0000 (22:37 +1100)
committerSasha Levin <sasha.levin@oracle.com>
Fri, 24 Apr 2015 21:14:13 +0000 (17:14 -0400)
commit48ca7d78ff4efccbf3d670774d29dd52b7af912d
treea4c5b8d74dc27af5f715d6f181e4e3be88c14800
parenta69957362258b8932fe4df1433b1fdea8072ba04
xfs: ensure truncate forces zeroed blocks to disk

[ Upstream commit 5885ebda878b47c4b4602d4b0410cb4b282af024 ]

A new fsync vs power fail test in xfstests indicated that XFS can
have unreliable data consistency when doing extending truncates that
require block zeroing. The blocks beyond EOF get zeroed in memory,
but we never force those changes to disk before we run the
transaction that extends the file size and exposes those blocks to
userspace. This can result in the blocks not being correctly zeroed
after a crash.

Because in-memory behaviour is correct, tools like fsx don't pick up
any coherency problems - it's not until the filesystem is shutdown
or the system crashes after writing the truncate transaction to the
journal but before the zeroed data in the page cache is flushed that
the issue is exposed.

Fix this by also flushing the dirty data in memory region between
the old size and new size when we've found blocks that need zeroing
in the truncate process.

Reported-by: Liu Bo <bo.li.liu@oracle.com>
cc: <stable@vger.kernel.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
fs/xfs/xfs_file.c
fs/xfs/xfs_inode.h
fs/xfs/xfs_iops.c