Re: Btrfs send with parent different size depending on source of files.

From: Chris Murphy <lists@colorremedies.com>
To: Remi Gauvin <remi@georgianit.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Btrfs send with parent different size depending on source of files.
Date: Fri, 15 Feb 2019 11:38:34 -0700	[thread overview]
Message-ID: <CAJCQCtRTOcCttXm_pP5nnxnfn86ApgPxSPu81ffvQGBTNPKZ+g@mail.gmail.com> (raw)
In-Reply-To: <d8a2685c-1844-fd01-de2b-00425458df2a@georgianit.com>

On Thu, Feb 14, 2019 at 9:00 PM Remi Gauvin <remi@georgianit.com> wrote:
>
>
> > It doesn't work this way. The snapshots a and b are not based on the
> > same underlying subvolume. The gist is that you would keep changing A,
> > and take additional snapshots of A, such as a.1 a.2 a.3, and you can
> > do incremental send with 'btrfs send -p a.1 a.2' which describes the
> > difference between those two snapshots of A at their respective
> > moments in time. You could also do 'btrfs send -p a.2 a.3' or even
> > 'btrfs send -p a.1 a.3'
> >
> > But as there's no relationship between
>
> snapshots a and b, I consider
> > it a bug/missing error handling feature, that btrfs send doesn't fail
> > in this case. By using -p you're claiming there is a parent-child
> > relationship between a and b, but there plainly isn't.
>
> They kind of are related though, since the two snapshots reference the
> same data blocks, and you can see it work in the first example with the
> 40MB of random data.

Is it more of a case for clone, -c option? I don't ever use it, and
the man page could use a couple examples to make it more clear what it
can do. And it makes sense this option could be more tolerant, less
error checking, than -p.

But from man page and in particular the wiki, it's clear to me that
the two snapshots following -p option, need to each be derived from
one subvolume. I actually don't like the "parent - child" metaphor
because really the parent is the original source rw subvolume, and its
two children snapshots are the ones used with -p. The first is an
older sibling, the second a younger sibling. And that metaphor fails
too because you'd expect the second sibling to have more information
which plainly is not the case with actual siblings. :P

> The out file is only 773 bytes.  However, if you repeat all those same
> steps, but replace the dd with:
> wget -O A/dir/server.jar
> https://launcher.mojang.com/v1/objects/20c069d373e77265aaeeedb733f7051e294325a3/server.jar
>
> The resulting out file is 34MB.

Well I'd say maybe use -vvv and --no-data instead of -f and see what
it's doing. It sounds like the former has no payload, just difference
information, and the latter has a payload. I don't know why.

--
Chris Murphy