RFC: Btrfs snapshots feature for F13

[Josef Bacik]

On Tue, Nov 17, 2009 at 2:09 PM, Peter Jones <pjones at redhat.com> wrote:
> 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.
>

It doesn't.  Userspace transactions are _only_ to make sure that a set
of operations go to disk at the same time.  The original reason this
was implemented was for ceph, a distributed filesystem that has a
client that runs in userspace and needs to write to an inode and
update an xattr on that inode at the same time in order to maintain
filesystem consistency.  Nowadays there is _no_ guarantee that the
write to the inode and the write to the xattr will go into the same
transaction, so the userspace transaction just makes sure that they do
happen in the same transaction.  It's not a snapshot or anything like
that, its just a way to guarantee ordering.  Thanks,

Josef