Re: is back and forth incremental send/receive supported/stable?

[Hugo Mills <hugo@carfax.org.uk>]

On Sun, Jan 31, 2021 at 11:50:22PM +0100, Christoph Anton Mitterer wrote:
> Hey Hugo.
> 
> 
> Thanks for your explanation.
> I assume such a swapped send/receive would fail at least gracefully?

   It'll fail *obviously*. I'm not sure how graceful it is. :)

> On Fri, 2021-01-29 at 19:20 +0000, Hugo Mills wrote:
> >    In your scenario with MASTER and COPY-1 swapped, you'd have to
> > match the received_uuid from the sending side (on old COPY-1) to the
> > actual UUID on old MASTER. The code doesn't do this, so you'd have to
> > patch send/receive to do this.
> 
> Well from the mailing list thread you've referenced it seems that the
> whole thing is rather quite non-trivial... so I guess it's nothing for
> someone who has basically no insight into btrfs code ^^
> 
> It's a pity though, that this doesn't work. Especially the use case of
> sending back (backup)snapshots would seem pretty useful.
> 
> Given that this thread is nearly 6 years, I'd guess the whole idea has
> been abandoned upstream?!

   It can be made to work, in a number of different ways -- the option
above is one way; another would be to add extra history of subvolume
identities -- but I guess it's not a priority for the devs, and at
least the latter approach would require extending the on-disk FS
format. Both approaches would need changes to the send stream format.

   Hugo.

-- 
Hugo Mills             | Great oxymorons of the world, no. 7:
hugo@... carfax.org.uk | The Simple Truth
http://carfax.org.uk/  |
PGP: E2AB1DE4          |