On Tue, Jan 22, 2019 at 10:57 AM Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote: > > 22.01.2019 9:28, Chris Murphy пишет: > > 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. > > > > "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
