inconsistent send/receive behavior

inconsistent send/receive behavior

[john terragon]

Hi.
Let's consider the following send/receive example

-two btrfs FS /btrfsA /btrfsB
-one subvol vol in /btrfsA
-btrfs sub snap -r vol vol1_RO
-btrfs send /btrfsA/vol1_RO | btrfs receive /btrfsB
-then, in /btrfsB:
      btrfs sub snap vol1_RO vol
-do some work on /btrfsB/vol
-then in /btrfsB:
      btrfs sub snap -r vol vol2_RO
-then from /btrfsB:
-btrfs send -p vol1_RO vol2_RO | btrfs receive /btrfsA

So, the initial seeding is from btrfsA to btrfsB and then there is an
incremental send "in reverse" from btrfsB ro btrfsA.

Is something like this supposed to work?

Because I've got cases in which it seems to work (no error or data
loss that I can see) and cases in which the "reverse incremental send"
does send stuff back for a while and it creates the vol2_RO subvolume
but then it ends up throwing an

ERROR: clone: did not find source subvol

So, it does not say that immediately at the start. It seemingly does
all the work before complaining.
And the resulting vol2_RO in btrfsA seems to be OK.
du /brtfsA/vol2_RO reports a size that's close to the one of /brtfsB/vol2_RO.
And df reports that /brtfsA/vol2_RO seems to be using a fraction of
its reported size by du.

So, at the very least, even if this "reverse incremental send" is not
supposed to work in btrfs, there is inconsistent behavior of the FS
and/or the btrfs tool.

Thanks
John

Re: inconsistent send/receive behavior

[Andrei Borzenkov]

On 01.08.2021 10:19, john terragon wrote:
> Hi.
> Let's consider the following send/receive example
> 
> -two btrfs FS /btrfsA /btrfsB
> -one subvol vol in /btrfsA
> -btrfs sub snap -r vol vol1_RO
> -btrfs send /btrfsA/vol1_RO | btrfs receive /btrfsB
> -then, in /btrfsB:
>       btrfs sub snap vol1_RO vol
> -do some work on /btrfsB/vol
> -then in /btrfsB:
>       btrfs sub snap -r vol vol2_RO
> -then from /btrfsB:
> -btrfs send -p vol1_RO vol2_RO | btrfs receive /btrfsA
> 
> So, the initial seeding is from btrfsA to btrfsB and then there is an
> incremental send "in reverse" from btrfsB ro btrfsA.
> 
> Is something like this supposed to work?
> 

No. /btrfsB/vol does not exist on /btrfsA, so any reference to
/btrfsB/vol cannot be resolved on /btrfsA.

> Because I've got cases in which it seems to work (no error or data
> loss that I can see) and cases in which the "reverse incremental send"
> does send stuff back for a while and it creates the vol2_RO subvolume
> but then it ends up throwing an
> 
> ERROR: clone: did not find source subvol
> 
> So, it does not say that immediately at the start. It seemingly does
> all the work before complaining.
> And the resulting vol2_RO in btrfsA seems to be OK.
> du /brtfsA/vol2_RO reports a size that's close to the one of /brtfsB/vol2_RO.
> And df reports that /brtfsA/vol2_RO seems to be using a fraction of
> its reported size by du.
> 
> So, at the very least, even if this "reverse incremental send" is not
> supposed to work in btrfs, there is inconsistent behavior of the FS
> and/or the btrfs tool.
> 

btrfs send builds stream incrementally. It does not really know that it
will need reference to /btrfsB/vol until it actually sees this part. So
btrfs receive cannot verify whether it will fail. It processes input
stream as far as it can - this will be data unchanged between
/btrfsB/vol1_RO and /btrfsB/vol.