Btrfs: send, don't bug on inconsistent snapshots
authorFilipe Manana <fdmanana@suse.com>
Mon, 1 Aug 2016 00:50:37 +0000 (01:50 +0100)
committerFilipe Manana <fdmanana@suse.com>
Mon, 1 Aug 2016 06:31:41 +0000 (07:31 +0100)
commit951555856b88aa47bc238de6b4c6e97bfd9d36df
tree2c593dc8a659d69f5b92d6bfc3c7ba5b0fe2d046
parent15b253eace1f98dabbc6e03f6793fcf8603b1655
Btrfs: send, don't bug on inconsistent snapshots

When doing an incremental send, if we find a new/modified/deleted extent,
reference or xattr without having previously processed the corresponding
inode item we end up exexuting a BUG_ON(). This is because whenever an
extent, xattr or reference is added, modified or deleted, we always expect
to have the corresponding inode item updated. However there are situations
where this will not happen due to transient -ENOMEM or -ENOSPC errors when
doing delayed inode updates.

For example, when punching holes we can succeed in deleting and modifying
(shrinking) extents but later fail to do the delayed inode update. So after
such failure we close our transaction handle and right after a snapshot of
the fs/subvol tree can be made and used later for a send operation. The
same thing can happen during truncate, link, unlink, and xattr related
operations.

So instead of executing a BUG_ON, make send return an -EIO error and print
an informative error message do dmesg/syslog.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
fs/btrfs/send.c