Re: Incremental receive completes succesfully despite missing files

[Dennis Katsonis <dennisk@netspace.net.au>]

On 1/23/19 10:25 PM, Andrei Borzenkov wrote:
> On Wed, Jan 23, 2019 at 1:45 PM Dennis Katsonis <dennisk@netspace.net.au> wrote:
>> I think my previous e-mail did not go through.  Basically, if it is
>> assumed that a btrfs-receive operation will result in a subvolume which
>> matches the source file for file, then this assumption or expectation
>> won't be met if one deletes files from the subvolume at the receiving
>> end which is going to be referred to as the parent.
>>
> 
> This is oxymoron. btrfs send/receive apply to read-only subvolumes.
> You are not able to modify them. 


> 
>> This can happen inadvertently,
> 
> It cannot. You do not inadvertently make subvolume read-write. 
It's not the individual steps which happen inadvertently, its that
particular workflow which can happen (i.e.; someone decides to play
around with a replicated snapshot, and flips the ro bit to do so).  Any
subsequent children sent later won't be true replicates on the receiving
end.

They would have to either make a habit of not flipping that ro bit at
all (there is nothing to say don't do it, and there are valid reasons to
do so) or anticipate they may need that subvolume as a parent anytime in
the future and that parents must be the same on both ends (there is
nothing which states that parents have to be identical on both ends for
btrfs-receive to operate).  If they do modify ANY subvolume created by
btrfs-receive, they must remember in the future somehow never to use
them as parents.

BTRFS allows an ad-hoc, unstructured approach to managing snapshots and
replication, but the cost I suppose is there are more corner cases and
more potential for users to use the system in a manner which differs
from the devs.


> 
> That said, better if btrfs did not allow flipping read-only bit in the
> first place.
> 
>> or even through filesystem corruption
>> (which I experienced).
>>
> 
> And if corruption happened after applying changes? End result in the
> same. Of course it would be perfect if btrfs could notice and warn
> you, I just do not see how it can realistically be implemented.
>If the tools can't prevent it, the documentation should, and should also
ideally describe the mode of failure (i.e., if the subvolumes are
different, btrfs-receive won't necessarily fail, but can produce a
subvolume which is not identical to that sent.

At the moment, one must infer that the statement that clones must be
identical at both ends.