On Sun, Jul 12, 2020 at 5:39 AM Andy Mender <andymenderunix@gmail.com> wrote:
>
>On updates, a single automatic corrupted snapshot can
> potentially hose the entire snapshotted volume.

How do you mean? If this is a sort of superficial corruption like a
bad/failed/partial update, inconsistency between package manager and
what's installed - this can be self-contained to a specific snapshot.
One possible idea for updates is snapshot and do the update out of
band (not the current running sysroot) on a snapshot. If the update
fails for whatever reason, destroy the snapshot. Corruption that
affects multiple subvolumes wouldn't be related to snapshotting, but
the shared trees: extent, chunk, csum, uuid, etc. trees.

>Also, if your system is almost broken after the change,
> no snapshot will help.

I'm not sure about the nature of the brokenness in your example. Btrfs
does have a concept of a volume wide snapshot, which is the seed
device. The file system is merely marked read-only, but can have a
second device added that accepts all writes. If this two device volume
were to become irreversibly confused, it'd still be possible to revert
to the read-only device - even temporarily - as a kind of "recovery"
boot. With extreme prejudice, a true factory reset is possible by
wiping the read-write 2nd device and starting over. It's also possible
to use it for replication - by adding a 2nd device and removing the
1st, an exact copy is made. This is a whole separate ball of wax, and
while there are ideas how it might be leveraged, there's no plan to do
so yet.