RFC: Btrfs snapshots feature for F13

[Josef Bacik]

On Tue, Nov 17, 2009 at 1:33 PM, James Antill <james at fedoraproject.org> wrote:
> On Tue, 2009-11-17 at 11:48 -0500, Tom Lane wrote:
>> Peter Jones <pjones at redhat.com> writes:
>> > Do they support rollbacks after commit?  If they don't, they're not
>> > really as useful for this as they could be.
>>
>> Rollback *after* commit?  This must be some other usage of the term
>> "commit" than is standard to database people.
>
>  No it's just a new definition of "rollback" than is standard. The idea
> is that _ideally_ people seem to _want_ to be able to do:
>
> 1. update to new foo
> 2. run random other things that alter data.
> 3. update to new bar
> 4. run random other things that alter data.
> 5. run new foo, which alters it's data.
> 6. run random other things that alter data.
> 7. run new bar, which alters it's data.
> 8. run random other things that alter data.
> 9a. Decide foo is bad and thus. "rollback" just #1 and #5.
> 9b. Decide bar is bad and thus. "rollback" just #3 and #7.
>
> ...so all solutions tend to be exercises in randomly picking the
> features you think they really want, from what is desired.
>
>  Yum history assumes you are happy with just #1 and/or #3.
>
>  Snapshots assume you are happy to take a lot of collateral damage to
> get #5 and/or #7.
>

Sure, this isn't a perfect solution, it's just a nice to have feature
if you care for it.  It's nice to take a complete snapshot of your
system right before you update just in case something goes horribly
wrong and you lose say configuration files or some such.  If you
modified other things and have to rollback, you can always just mount
the newer snapshot when you boot into the old snapshot and copy the
new data that you want back.  This isn't for the faint of heart, I
envisioned it really for people who want to play the rawhide game with
less exposure to its instability.  Thanks,

Josef