On 23.01.19 г. 17:25 ч., Hans van Kranenburg wrote:
> On 1/23/19 12:25 PM, Andrei Borzenkov wrote:
>> On Wed, Jan 23, 2019 at 1:45 PM Dennis Katsonis <denn...@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.
I had a patch which when the ro bit is flipped on a snapshot, then it's
parent snapshot uuid etc is deleted. Because at that point it cannot be
guaranteed that there is any relationship between paren<->snapshot. Ie:
https://lore.kernel.org/linux-btrfs/1520847020-8049-1-git-send-email-nbori...@suse.com/
has anyone tried it?
>
>>> 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.
>>
>
>
