Partial snapshot updates?

[Gooberpatrol66]

Partial snapshot updates?

[Gooberpatrol66]

Screwed up the post.

[eugene-bright]

No space left on device - is a badly btrfs bugs symptom.
Kernel update and btrfs filesystem balancing are recommended
https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_get_.22No_space_left_on_device.22_errors.2C_but_df_says_I.27ve_got_lots_of_space

[Gooberpatrol66]

I don't think it's bugged, it's just full of partial snapshots from retrying this. The --delete option doesn't work either btw

[eugene-bright]

Talking in respect of btrfs snapshot transfer resuming I'm almost sure that it's impossible.
As I know btrfs send stream consists of encoded commands such as "create new file", "append this", "replace that". btrfs receive just does all this things from userspace as a normal application (doing only minor actions with ioctl calls: such as setting received UUID of volume and marking it read only).
So, there is no idempotence. Double appending would break the things.
Also I'm not aware if btrfs keep track of stream applying. If the number of last successfully applied command had been known it would have been possible to skip the part of stream next time. But it's a theory the implementation of which is not known to me.
For now you can manually store btrfs send stream as a local file, rsync it to another host and then apply it on the remote machine.

[eugene-bright]

For the full history please attach uname -a output to this issue.

[eugene-bright]

And one more thing.
Buttersink in a promising tool. But it's currently practically unmaintained.
I somehow tuned my own fork for my tasks.
Btrfs quota performance make current algorithm of btrfs <-> btrfs transferring impractical. See #62.
We need egg-headed hero to refactor buttersink massively to work it around.

[AmesCornish]

As Eugene commented, we would need btrfs send and receive to support resuming, which they currently don't.