On Mon, Jan 21, 2019 at 11:00 PM Remi Gauvin <remi@xxxxxxxxxxxxxx> 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.
> 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.
--
Chris Murphy
