On 11/17/2009 02:15 PM, Josef Bacik wrote:
> On Tue, Nov 17, 2009 at 2:09 PM, Peter Jones <pjones@xxxxxxxxxx> wrote:
>> On 11/17/2009 11:48 AM, Tom Lane wrote:
>>> Peter Jones <pjones@xxxxxxxxxx> 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,
Okay, so then I definitely don't see what jgarzik was getting at.
--
Peter
If you're not part of the solution, then you're part of the precipitate.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
