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. > >> 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. "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 ...
