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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
