On Sun, Jul 12, 2020 at 5:39 AM Andy Mender <andymenderu...@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. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
