Targeting "roughly okay backups" of a running system that uses BTRFS as filessytem, I seek an answer regarding
Can option
- a)
btrfs filesystem sync <path>(sync(1)) be used to force an "okay" filsystem state of "persisted on disk" data, similar to option - b)
btrfs subvolume snapshot, which I assume to be the "correct way", yet seems not to be without issues?
The issue I fear with option b) is from this thread of the btrfs mailing list:
Snapshot create has unbounded running time on 5.0 kernels. The creation process has to flush dirty buffers to the filesystem to get a clean snapshot state. Any process that is writing data while the flush is running gets its data included in the snapshot flush, so in the worst possible case, the snapshot flush never ends (unless you run out of disk space, or whatever was writing new data stops, whichever comes first).
In essence I wonder how the option a) is actually different here, in that it would not suffer from a heavy-writer program outrunning the efforts of btrfs to create a synced state?
Being new to btrfs it might also be an unfounded fear, and the cow nature of btrfs will have an "okay" persisted on disk state, if so a reference (that I must have missed) regarding those guarantees would also resolve the issue of this question.
