Re: Incremental receive completes succesfully despite missing files

[Hans van Kranenburg <Hans.van.Kranenburg@mendix.com>]

On 1/23/19 12: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. As soon as you remove read-only bit,
> you are fully responsible for consequences.
> 
>> This can happen inadvertently,
> 
> It cannot. You do not inadvertently make subvolume read-write. And if
> you do, you are expected to know what you are doing.
> 
> That said, better if btrfs did not allow flipping read-only bit in the
> first place.

+100

But then only disallow if the subvol has a value in the received_uuid
field, I'd say.

And the tooling could display a nice error message, telling the user to
make a rw snapshot of the received subvol instead, which will have an
empty received_uuid field again.

ERROR: subvolume is a received subvolume, which cannot be made read-write
ERROR: suggestion; make a read-write snapshot of it instead

Setting something ro manually (e.g. to prevent accidental deletion of a
static set of data) is still also a use case.

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


-- 
Hans van Kranenburg