When 'btrfs send -p <oldsnapshot> <newsnapshot>' is used for incremental backups and the source filesystem has the no-holes flag set, the sendstream not only contains actual filedata differences for files between the 2 snapshots, but also content that seems to represent the sparse part of (a) file(s) that is changed between 2 snapshots.

The sparse part of a file is not changed by definition, so it should not be added to the differential sendstream.

The shell command sequence below reproduces the problem (btrfs-progs version 4.6.1 was used, but problem is the same for kernel 4.6.2 + progs 4.5.3

If the btrfstune command is left out, the sendstream has the expected size of ~1M, otherwise it is ~4G


truncate -s 5G /holetest.img
losetup /dev/loop0 /holetest.img
mkfs.btrfs /dev/loop0
btrfstune -n /dev/loop0
btrfs-show-super /dev/loop0 | grep incompat_flags
mount /dev/loop0 /mnt
btrfs sub create /mnt/vol1
truncate -s 4G /mnt/vol1/test1
btrfs sub snap -r /mnt/vol1 /mnt/vol1.ro0
dd if=/dev/urandom of=/mnt/vol1/test1 bs=1M count=1 conv=notrunc
sync
btrfs sub snap -r /mnt/vol1 /mnt/vol1.ro1
dd if=/dev/urandom of=/mnt/vol1/test1 bs=1M count=1 conv=notrunc
sync
btrfs sub snap -r /mnt/vol1 /mnt/vol1.ro2
btrfs send -p /mnt/vol1.ro1 /mnt/vol1.ro2 > /sendstream.btrfs
ls -al /sendstream.btrfs
umount /mnt
losetup -d /dev/loop0
rm /holetest.img /sendstream.btrfs