Re: Incremental receive completes succesfully despite missing files

[Chris Murphy <lists@colorremedies.com>]

On Tue, Jan 22, 2019 at 10:57 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>
> 22.01.2019 9:28, Chris Murphy пишет:
> > On Mon, Jan 21, 2019 at 11:00 PM Remi Gauvin <remi@georgianit.com> wrote:
> >>
> >> On 2019-01-21 11:54 p.m., Chris Murphy wrote:
> >> #
> >>>
> >>> I expect the last command to fail because 1.ro1 is not the parent of
> >>> 2.ro2. The command completes, and 2.ro2 is on the destination, and at
> >>> least in this simple example it contains the expected files. However
> >>> 'btrfs show' indicates that the "parent UUID" of 2.ro2 is the "UUID"
> >>> of 1.ro1, which is definitely wrong. So it's a legit bug, not just a
> >>> cosmetic problem due to lack of error checking.
> >>>
> >>
> >>
> >> This is, as far as I understand, exactly how it's *supposed* to work, at
> >> least, as documented.  The only relationship needed between a "parent"
> >> snapshot, and the snapshot you're sending, is that the parent already
> >> exists on the destination.
> >
> > I disagree. From the man page:
> >
> >        -p <parent>
> >            send an incremental stream from parent to subvol
> >
> > You have to understand that the send and receive commands is a
> > unidirectional stream. The receive command can't talk to the send
> > side. It can only pass or fail. So to get the correct incremental send
> > stream, the send command must be correctly formed based on specific
> > parent child relationship.
> >
>
> "Parent" is too ambiguous in btrfs as it is used to denote completely
> independent things. Snapshot parent-child relationship is unrelated to
> "parent" as used in "btrfs send".
>
> Subvolume referred to by "btrfs send -p" is used as base to compute
> changes against. Nothing more nothing less. There is no implication that
> subvolume that is being transferred is snapshot of subvolume referred to
> by -p argument. Actually the most common scheme is - you have base
> subvolume "base"m you periodically create snapshots from these subvolume
> as "btrfs sub snap -r base snap1", "btrfs sub snap -r base snap2" etc
> and then do incremental transfer between each snapshots as "btrfs send
> -p snap1 snap2" etc. Neither of "snapX" is snapshot of another "snapX".
> You have fan-out structure on source and linear structure on destination.

base is the parent of all snapX

A totally unrelated subvolume "noodle" being used as -p is obviously
user error, it doesn't matter if it doesn't cause corruption. For sure
the resulting subvolume has the wrong "parent UUID" as a result, so
there are at least two unintended consequences.


> >>  Your example would be completely
> >> counter-productive, since there is no data shared between the two, but
> >> perfectly legitimate.  1.ro1 is the parent of 2.ro2 because *you
> >> explicitly told it to*.
> >
> > It's not legitimate, it's a mistake by the user. The actual stream
> > ends up being a full send of 2.ro2, rather than an incremental, and
> > then on the destination 2.ro2 ends up showing a parent UUID for a
> > subvolume that's totally unrelated. It's just not sane.
> >
> >
>
> It is still entirely legal operation. The result will be full
> replication stream of 2.ro2 + additional instructions to delete content
> of (clone of) 1.ro1 on destination.

Which is utterly absurd because the user, by virtue of using -p flag,
is indicating they want an incremental send and yet silently they will
not get an incremental send. They very clearly made a mistake.

> "Related" is in the eye of the beholder. Clone subvolume, delete content
> of clone, reflink content of another volume into clone. Are original
> subvolume and clone related now? Clone still have parent UUID ...

I'm not talking about -c option. Just -p. Conceptually -c is even more
complicated and effectively supports multiple "parents" as it can be
specified more than once.




-- 
Chris Murphy