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

[Andrei Borzenkov <arvidjaar@gmail.com>]

15.02.2019 22:11, Chris Murphy пишет:
...
>>>
>>> It doesn't work this way.
>>
>> It works exactly this way.
> 
> Unproven. And in fact we have an example where it does not work, hence
> the point of the thread!
> 
> The proven way it works, is as I've described, and many emails over a
> decade on this list, inferred from the man page, and the step by step
> recipe on the Wiki.
> 

Oh well.

10:~ # mkfs -t btrfs -f /dev/sdb1
btrfs-progs v4.20.1
See http://btrfs.wiki.kernel.org for more information.

Label:              (null)
UUID:               c8dd61f1-bf32-449b-a154-3380cf4348b5
Node size:          16384
Sector size:        4096
Filesystem size:    1023.00MiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP              51.12MiB
  System:           DUP               8.00MiB
SSD detected:       no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1  1023.00MiB  /dev/sdb1

10:~ # mount -t btrfs /dev/sdb1 /mnt
10:~ # cd /mnt
10:/mnt # btrfs su cr A
Create subvolume './A'
10:/mnt # mkdir A/dir
10:/mnt # dd if=/dev/urandom of=A/dir/server.jar bs=1024 count=40K
40960+0 records in
40960+0 records out
41943040 bytes (42 MB, 40 MiB) copied, 0.380302 s, 110 MB/s
10:/mnt # btrfs su sn -r A a1
Create a readonly snapshot of 'A' in './a1'
10:/mnt # cp --reflink=always A/dir/server.jar A/server.jar
10:/mnt # btrfs su sn -r A a2
Create a readonly snapshot of 'A' in './a2'
10:/mnt # btrfs send -p a1 a2 > out
At subvol a2
10:/mnt # ll -sh out
4.0K -rw-r--r-- 1 root root 567 Feb 16 23:15 out
10:/mnt # cd
10:~ # umount /mnt
10:~ # mkfs -t btrfs -f /dev/sdc1
btrfs-progs v4.20.1
See http://btrfs.wiki.kernel.org for more information.

Label:              (null)
UUID:               a2d85827-116a-4dee-874c-d3b180728613
Node size:          16384
Sector size:        4096
Filesystem size:    1023.00MiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP              51.12MiB
  System:           DUP               8.00MiB
SSD detected:       no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1  1023.00MiB  /dev/sdc1

10:~ # mount -t btrfs /dev/sdc1 /mnt
10:~ # cd /mnt
10:/mnt # btrfs su cr A
Create subvolume './A'
10:/mnt # mkdir A/dir
10:/mnt # dd if=/dev/urandom of=A/dir/server.jar bs=1024 count=34625
34625+0 records in
34625+0 records out
35456000 bytes (35 MB, 34 MiB) copied, 0.31223 s, 114 MB/s
10:/mnt # btrfs su sn -r A a1
Create a readonly snapshot of 'A' in './a1'
10:/mnt # cp --reflink=always A/dir/server.jar A/server.jar
10:/mnt # btrfs su sn -r A a2
Create a readonly snapshot of 'A' in './a2'
10:/mnt # btrfs send -p a1 a2 > out
At subvol a2
10:/mnt # ll -sh out
34M -rw-r--r-- 1 root root 34M Feb 16 23:17 out
10:/mnt #


>>> 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.
> 
> That's fair. But also the alternative cannot be stated to "work
> exactly this way" when this very thread starts with two examples
> leading to different and therefore unexpected results, differing only
> in how the file was created: dd vs wget
> 

It is not the *only* difference between two examples.

> And no one can explain that. 

I just sent explanation why it happens.

...
>>
>> 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.
> 
> man page and wiki use incremental - and linguistically incremental !=
> differential, increment is a subset of difference.
> 

btrfs send computes differential stream. Whether it will be
"incremental" or not depends on how you are using it.

> Difference suggests the order does not matter. Increment suggests it
> does matter.
> 
> btrfs sub create A
> cp somestuff A
> btrfs sub snap -r A a.1
> cp morestuff A
> btrfs sub snap -r A a.2
> 
> The normal case of send is:
> 
> btrfs send -p a.1 a.2
> 
> However, is it valid to do?
> 
> btrfs send -p a.2 a1
> 

Of course it is. Stream contains differences between the first and the
second stream, where order does matter. "Incremental" implies temporal
ordering between two snapshots which does not exist on "btrfs send"
level and must be ensured by tools that use "btrfs send/receive". There
is no inherent parent/child or temporal relationship implied by "btrfs
send" itself. "btrfs send" *will* compute differences from a.1 to a.2
although a.2 is newer than a.1; it is up to you to ensure you apply this
stream to correct base on destination.