After deduplicating a filesystem containing a parent snapshot using bees, doing an incremental btrfs send fails with the following in dmesg: [57807.246706] BTRFS error (device dm-2): Send: inconsistent snapshot, found updated extent for inode 8924138 without updated inode item, send root is 4457, parent root is 4425 Note: This isn't related to the fix that's in kernel 5.2 since the send and deduplication didn't occur simultaneously. See https://github.com/Zygo/bees/issues/115
So I tried the following: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ xfs_io -f -c "pwrite -S 0xab 0 1M" /mnt/foo $ btrfs subvolume snapshot -r /mnt /mnt/snap1 $ xfs_io -f -c "pwrite -S 0xab 0 1M" /mnt/bar $ btrfs subvolume snapshot -r /mnt /mnt/snap2 # deduplicate foo into bar, so that both point to the same extent(s) $ xfs_io -c "dedupe /mnt/snap2/foo 0 0 1M" /mnt/snap2/bar # do the incremental send, see if it fails $ btrfs send -p /mnt/snap1 -f /dev/null /mnt/snap2 $ echo $? 0 dmesg/syslog is also clean. Applying send streams to a filesystem also shows both files are there and with correct content. Can you provide more details on how the deduplication is being done exactly? Full, just same extents, order, etc. Also, any special mount options? Thanks.
So I managed to find out how it happens exactly, it's not that trivial to reproduce and happens sort of randomly, no wonder why I have not ever hit it or had other user reports before. I'll send a fix soon (this week) to the btrfs mailing list.
Sent: https://lore.kernel.org/linux-btrfs/20190717122339.4926-1-fdmanana@kernel.org/T/#u https://lore.kernel.org/linux-btrfs/20190717122439.28327-1-fdmanana@kernel.org/T/#u
Thanks for the report and fix. Patch queued for 5.3, closing.