On 02/27/2012 10:51 AM, Paolo Bonzini wrote:
On 02/27/2012 04:24 PM, Anthony Liguori wrote:
Then you get an error with the block devices still frozen. You can
execute another command to reopen back to the old image to roll back the
transaction.
Pushing the rollback logic to the client does make the client interface
a bit more complicated and adds latency to the error path but it's much
easier than building a complex transaction infrastructure.
And there are examples of this in the wild too. LDAP uses a similar
mechanism.
Actually, have you seen Jeff's atomic snapshot patch? It really
implements all that is needed to do transactions, and gets 100% ok
error-recovery unlike the existing blockdev_snapshot_sync. It really
looks like we can do better than client-side error management, and there
is not that much complexity at all.
Jeff could rework his patches to work with transaction begin/commit
commands, and Federico can then add drive-reopen and drive-migrate on top.
Yes, maybe I lack imagination but I fail to see how it generalizes
easily/nicely.
From what I can tell, all of the rollback logic is very specific to the
commands being used, right?
Regards,
Anthony Liguori
Paolo
