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.
