commit 8c6c592831a09a28428448e68fb08c6bbb8b9b8b
author Josef Bacik <jbacik@fb.com> Tue Aug 29 10:11:39 2017 -0400
committer David Sterba <dsterba@suse.com> Tue Sep 26 14:54:16 2017 +0200
tree 9d4fc8af84cb616475a140b0fcebf08ba1bff0d1
parent 99c4e3b96c797f047be4e6b7c03cfca01959f146

btrfs: log csums for all modified extents

Amir reported a bug discovered by his cleaned up version of my
dm-log-writes xfstests where we were missing csums at certain replay
points.  This is because fsx was doing an msync(), which essentially
fsync()'s a specific range of a file.  We will log all modified extents,
but only search for the checksums in the range we are being asked to
sync.  We cannot simply log the extents in the range we're being asked
because we are logging the inode item as it is currently, which if it
has had a i_size update before the msync means we will miss extents when
replaying.  We could possibly get around this by marking the inode with
the transaction that extended the i_size to see if we have this case,
but this would be racy and we'd have to lock the whole range of the
inode to make sure we didn't have an ordered extent outside of our range
that was in the middle of completing.

Fix this simply by keeping track of the modified extents range and
logging the csums for the entire range of extents that we are logging.
This makes the xfstest pass.

Reported-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>