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

[Andrei Borzenkov <arvidjaar@gmail.com>]

15.02.2019 1:37, Chris Murphy пишет:
> On Thu, Feb 14, 2019 at 4:37 AM André Malm <admin@sheepa.org> wrote:
>>
>> Hello,
>>
>> I'm not sure this is the right forum to ask on but I'll try and if its
>> not I do apologize. I have also created a stack overflow question
>> without success (
>> https://stackoverflow.com/questions/54634703/btrfs-send-with-parent-different-size-depending-on-source-of-files
>> ) but ill paste the question here too. Thank you.
>>
>> What i'm trying to achieve is sending only the diff of the parent with
>> btrfs send -p
>>
>> Running this will produce a file 'out' with size 639 bytes, i.e only
>> diff sent.
>>
>> ====================================================
>>
>> btrfs subvolume create A
>> btrfs subvolume create B
>> mkdir A/dir
>>
>> dd if=/dev/urandom of=A/dir/server.jar bs=1024 count=40K
>> cp --reflink=always A/dir/server.jar B/server.jar
>>
>> btrfs subvolume snapshot -r A a
>> btrfs subvolume snapshot -r B b
>> btrfs send -p a b > out
> 
> It doesn't work this way.

It works exactly this way.

> The snapshots a and b are not based on the
> same underlying subvolume.

So what? What prevents you from computing differences between two
subvolumes? That is real question.

> 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'
> 

That it is intended to be used this way does not mean it is restricted
to this way technically. Whether it should have been restricted is
another question.

> 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.
> 

No. By using "-p" you designate subvolume which must be used as base to
apply differential (I explicitly does not use "incremental") stream on
remote side. Nothing more. Whether it should have different semantic is
subject to discussion, but it does not do what you wish it to do.

> Read this:
> https://btrfs.wiki.kernel.org/index.php/Incremental_Backup#Doing_it_by_hand.2C_step_by_step
> 
> Depending on your use case if you can describe it, might be tolerated
> with some adjustments by using the -c clone option instead.
> 

The only difference is that "-c" in absence of explicit "-p" attempts to
auto-detect the "best" "base" subvolume - but it selects between
subvolumes given with "-c" options so "-c" with single subvolume is
entirely equivalent to "-p".