On 1/23/19 4:32 PM, Nikolay Borisov wrote:
>
>
> 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?
Oh, it seems that one never got any reply.
When looking at it from an end user perspective, I'd much more like to
have it explicitly tell me I'm doing something stupid, refuse and
educate me than obeying and adding more implicit behaviour that I cannot
revert any more myself.
E.g. I'm a new btrfs user, I just sent this 1TiB of data for the first
time, and now I'm of course curious and trying more things out.
Trying setting rw ('ooh! that works') and then quickly setting ro back
will destroy the send/receive relationship without mentioning anything
to the user, and in combination with subsequent cryptic errors from
incremental send/receive ("cannot find parent subvolume" or something)
it will end up with smashing keyboards and throwing computers out of the
window.
After asking on IRC and providing output of btrfs sub list etc the user
is told that that subvol was never received because it doesn't have a
received_uuid, and then someone asks "did you turn it rw at some
point?". Now the user remembers, "yes, I was experimenting and I didn't
see an error or warning", and is then told to resend the 1TiB of data.
"But it's there already!" Now someone comes up with a snippet of python
code to reset the received_uuid with the ioctl, and...
:D
>>>> 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
