On Fri, Jan 25, 2019 at 7:43 PM Dennis Katsonis <dennisk@xxxxxxxxxxxxxxx> wrote:
>
> On 1/25/19 4:22 AM, Chris Murphy wrote:
> > On Thu, Jan 24, 2019 at 3:40 AM Dennis K <dennisk@xxxxxxxxxxxxxxx> wrote:
> >>
> >> The fact is, this thread is the first time I've seen explicitly written
> >> that parents must be the same at receiving and sending ends, or else
> >> btrfs-send/receive will produce a subvolume which differs from the source.
> >
> > The central user error, as well as btrfs-progs bug is the failure to
> > meet the requirement that the source(s) be snapshots. Either a full
> > send, or an incremental send, whether with -p or -c, all of them must
> > be snapshots. And none of yours were snapshots. They were read-only
> > subvolumes made using 'btrfs property' to set the read-only flag, and
> > those are not snapshots.
>
> Doesn't matter even if you only send snapshots and never set a subvolume
> to ro to please btrfs-send.
>
> # btrfs sub create 1
> # touch 1/file1
> # btrfs sub snap -r 1 2
> # btrfs send 2 | btrfs receive /destination
> !# sudo btrfs prop set /destination/2/ ro false
> !# rm /destination/2/file1
> # touch 1/file2
> # sudo btrfs sub snap -r 1 3
> # btrfs send -p 2 3 | btrfs receive /storage2/
> # ls /storage2/3/
> file2
> # ls 3/
> file1 file2
>
> The lines with the '!' are the source of the trouble, but it doesn't
> have to be rm. You could modify file 1 instead. It is obvious that
> users shouldn't do that, AFTER you've run through this sequence.
>
> Note that snapshot 2 at the receiving end was never set back to ro.
You're just finding more bugs (technically they are missing features,
as checking for user error is a feature); and I'm noticing there are
zero warnings in the man page for 'btrfs property' about unsetting ro
on snapshots. I agree with others that as soon as the ro flag is unset
on a snapshot, whatever metadata that makes it a snapshot and
references its parent, including both parent UUID and received UUIDs,
should be removed.
> You can also add an addition "rm /destination/snap2/file1" or even "rm
> -rf /destination/snap2/*" before the last rsync, and it still gives you
> a full replication.
>
> The expectation after running rsync without any explicit additional
> inclusion/exclusion clauses is replication, which is what it provides.
Not exactly. From man rsync:
>>>
Rsync finds files that need to be transferred using a "quick
check" algorithm (by default) that looks for files that have changed
in size or in last-modified
time. Any changes in the other preserved attributes (as
requested by options) are made on the destination file directly when
the quick check indicates that the
file’s data does not need to be updated.
>>>
If you initially replicate a destination using -r, the destination
files have *current* time stamps. Each additional -r causes
replication because the modification times for the source and
destination are different. If you initially use 'rsync -a' and then
follow it up with rsync -r, you'll see that the destination inodes
remain the same, no copy happens.
Anyway, if you're saying that rsync will at *worst* do an unnecessary
file copy, that's true and hence why -c exists; whereas with btrfs
send receive you can apparently successfully sabotage incremental send
receive by tampering with the receive side snapshot using 'btrfs
property' to unset ro, and remove a file; and a send/receive will not
make a subsequent receive side snapshot identical to the send side
source.
[chris@flap ~]$ ls -li test1/
total 1024
5185860 -rw-rw-r--. 1 chris chris 524288 Jan 26 15:55 file3
5185861 -rw-rw-r--. 1 chris chris 524288 Jan 26 15:55 file4
[chris@flap ~]$ ls -li test2/
total 1024
5185866 -rw-rw-r--. 1 chris chris 524288 Jan 26 15:55 file3
5185867 -rw-rw-r--. 1 chris chris 524288 Jan 26 15:55 file4
[chris@flap ~]$ rsync -rv test1/ test2/
sending incremental file list
sent 77 bytes received 12 bytes 178.00 bytes/sec
total size is 1,048,576 speedup is 11,781.75
[chris@flap ~]$ ls -li test1/
total 1024
5185860 -rw-rw-r--. 1 chris chris 524288 Jan 26 15:55 file3
5185861 -rw-rw-r--. 1 chris chris 524288 Jan 26 15:55 file4
[chris@flap ~]$ ls -li test2/
total 1024
5185866 -rw-rw-r--. 1 chris chris 524288 Jan 26 15:55 file3
5185867 -rw-rw-r--. 1 chris chris 524288 Jan 26 15:55 file4
[chris@flap ~]$
> > I'm still really not following where your confusion stems from, and
> > therefore I'm not sure what needs fixing other than the items I've
> > already mentioned - which itself at least would have stopped you in
> > your tracks, to go dig deeper or ask questions before arriving at the
> > understandably confusing results you were getting.
> >
>
> From the man page
>
> " btrfs receive will fail in the following cases:
>
> 1. receiving subvolume already exists
>
> 2. previously received subvolume has been changed after it was
> received
>
> 3. default subvolume has changed or you didn’t mount the
> filesystem at the toplevel subvolume
>
> A subvolume is made read-only after the receiving process
> finishes successfully (see BUGS below).
> "
>
> Point 2 is what you are referring to, but it doesn't fail. It reports
> success and doesn't return an error code to the shell. So the
> documentation could be improved by reflecting this fact, which can avoid
> users assuming that the snapshots at the receiving end must be the same
> because it didn't fail.
The bug is that it doesn't fail. I consider the documentation correct,
but the command behavior is wrong.
> Also, the btrfs-send man page could be improved, by including parents as
> well as clone sources as being required to be the same on both ends.
man btrfs send does say this for clones, but not for parents. And I
agree that the documentation needs to be more clear. Someone needs to
volunteer to make the changes and submit a patch.
>>>
You must not specify clone sources unless you guarantee that
these snapshots are exactly in the same state on both sides—both for
the sender and the receiver.
>>>
--
Chris Murphy
