btrfs: send with no-holes enabled, fallocate and hole punching
Test that an incremental send with not corrupt data when the source
filesystem has the no-holes feature enabled, a file has prealloc
(unwritten) extents that start after its size and hole is punched (after
the first snapshot is made) that removes all extents from some offset up
to the file's size.
This currently fails on any kernel version starting from 3.16, and it's
by a patch titled:
"Btrfs: incremental send, fix file corruption when no-holes feature is enabled"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>