Re: Possible to wait for snapshot deletion?

[Kai Krakow <hurikhan77+btrfs@gmail.com>]

Brendan Hide <brendan@swiftspirit.co.za> schrieb:

>> Is it technically possible to wait for a snapshot completely purged from
>> disk? I imagine an option like "--wait" for btrfs delete subvolume.
>>
>> This would fit some purposes I'm planning to implement:
>>
>> * In a backup scenario
>
> I have a similar use-case for this also involving backups. In my case I
> have a script that uses a btrfs filesystem for the backup store using
> snapshots. At the end of each run, if diskspace usage is below a
> predefined threshold, it will delete old snapshots until the diskspace
> usage is below that threshold again.

Yeah, I thought of that approach first, too... But:

> Of course, the first time I added the automatic deletion, it deleted far
> more than was necessary due to the fact that the actual freeing of
> diskspace is asynchronous from the command completion. I ended up
> setting a small delay (of about 60 seconds) between each iteration and
> also set it to monitor system load. If load is not low enough after the
> delay then it waits another 60 seconds.

Due to btrfs' behavior that cannot reliably work as you also figured out. It 
will need quirky work-arounds totally dependent on system load.

> This complicated (frankly broken) workaround would be completely
> unnecessary with a --wait switch.

That's why I had the idea. ;-)

> Alternatively, perhaps a knob where we can see if a subvolume deletion
> is in progress could help.

Like "btrfs scrub status"...

If you're feeling curious, here's what I've implemented yet (snapshot 
deletion still on the todo list):

https://gist.github.com/kakra/5520370

My idea is to fork-off a background process which constantly removes old 
snapshots (within sane bounds yet to be defined) and then exits. Some 
mechanism has to be found to not run into a deadlock situation here. Then, 
at the end issue a bash "wait" to join the processes again and run a final 
sync. However, I don't like to issue explicit syncs from within the 
subprocess as the filesystem is busy with rsync at the same time.

PS: Yes, I know there's btrfs send/receive - but it doesn't seem ready for 
the big show yet because it still has many strange quirks and should not be 
run unattended yet.

-- 
Replies to list only preferred.