RFC: Btrfs snapshots feature for F13

[Peter Jones]

On 11/17/2009 11:48 AM, 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.

So, I guess I should expand some more on what I'm saying.

The problem here is that normal database-like transactions don't help an
upgrade much, because you don't really know whether you want to commit the
changes until you've rebooted the machine and poked around for a bit.

Or, put another way, what you basically want is:

1 create an fs snapshot
2 do an upgrade
3 reboot machine
4 poke around
5 decide if it's good (6a) or bad (6b)
6 act on #5
  a - remove snapshot
  b - abandon all changes after the snapshot

And if you're talking about implementing that with database-like semantics,
then you want something non-traditional such as:

1 start transaction
2 upgrade
3 tentatively commit transaction
4 reboot machine
5 poke around
6 decide if it's good (6a) or bad (6b)
7 act on #6
  a - fully commit transaction
  b - roll back

These obviously aren't the traditional semantics, hence I'm asking if it has
semantics like that, because if it doesn't, then I don't really see Jeff's
point.

-- 
        Peter

If you're not part of the solution, then you're part of the precipitate.