Re: [PATCH 1/2] btrfs: protect snapshots from deleting during send

[Chris Mason <clm@fb.com>]

On 04/16/2014 09:32 AM, David Sterba wrote:
> On Tue, Apr 15, 2014 at 01:21:46PM -0400, Chris Mason wrote:
>>
>>
>> On 04/15/2014 12:27 PM, David Sterba wrote:
>>> On Tue, Apr 15, 2014 at 12:00:49PM -0400, Chris Mason wrote:
>>>>>> I'm worried about the use case where we have:
>>>>>>
>>>>>>    * periodic automated snapshots
>>>>>>    * periodic automated deletion of old snapshots
>>>>>>    * periodic send for backup
>>>>>>
>>>>>> The automated deletion doesn't want to error out if send is in progress, it
>>>>>> just wants the deletion to happen in the background.
>>>>>
>>>>> I'd give the precedence to the 'backup' process before the 'clean old
>>>>> snapshots', because it can do more harm if the snapshot is removed
>>>>> meanwhile without any possibility to recover.
>>>>
>>>> Right, we don't want either process to stop with an error.  We just want
>>>> them to continue happily and do the right thing...
>>>
>>> ... if everything goes without errors. Not like send going out of
>>> memory, send through network has a glitch, send to a file runs out of
>>> space, and has to be restarted. Is this too unrealistic to happen?
>>
>> It's a good point, a better way to say what I have in mind is that we
>> shouldn't be adding new transient errors to the send process (on purpose ;)
>
> Ok, I got a wrong understanding from your previous reply.
>
> So the next thing in the list to try is to add tunables affecting delete
> vs send. Something like
>
> $ btrfs send --protect-subvols -c clone1 -c clone2 source
>
> that would disallow to delete clone1, clone2 and source, passed to the
> ioctl as a flag and internally adding another refcount for 'how many
> times it has been protected'. Sounds ugly, but would cover all possible
> combinations of sending with or without deletion protection.
>

Ok, I reread the patch and your original point about dealing with a send 
+ delete + network interruption.  That's the part I didn't catch the 
first time around.

So in my example with the automated tool, the tool really shouldn't be 
deleting a snapshot where send is in progress.  The tool should be told 
that snapshot is busy and try to delete it again later.

It makes more sense now, 'll queue this up for 3.16 and we can try it 
out in -next.

-chris