Am 11.05.2015 um 15:10 hat Stefan Hajnoczi geschrieben: > On Fri, May 08, 2015 at 08:29:09AM -0600, Eric Blake wrote: > > On 05/08/2015 07:14 AM, Stefan Hajnoczi wrote: > > > > > No it doesn't. Actions have to appear atomic to the qmp_transaction > > > caller. Both approaches achieve that so they are both correct in > > > isolation. > > > > > > The ambiguity is whether "commit the changes" for .commit() means > > > "changes take effect" or "discard stashed state, making undo > > > impossible". > > > > > > I think the "discard stashed state, making undo impossible" > > > interpretation is good because .commit() is not allowed to fail. That > > > function should only do things that never fail. > > > > > >> That's going to get hard to maintain as we add more transactions. > > > > > > Yes, we need to be consistent and stick to one of the interpretations in > > > order to guarantee ordering. > > > > > > Unfortunately, there is already an inconsistency: > > > > > > 1. internal_snapshot - snapshot taken in .prepare() > > > 2. external_snapshot - BDS node appended in .commit() > > > 3. drive_backup - block job started in .prepare() > > > 4. blockdev_backup - block job started in .prepare() > > > > > > external_snapshot followed by internal_snapshot acts like the reverse > > > ordering! > > > > Is that fatal, though? > > Yes, ordering is critical when add-bitmap or clear-bitmap are combined > with drive-backup. Typically the drive-backup must happen after > add-bitmap or clear-bitmap.
Is there a reason to include add-bitmap/clear-bitmap in the transaction rather than preparing everything before the transaction and then only starting the backup (possibly of multiple disks) in a transaction? The original assumption was that there are no interdependencies between different transaction commands and the order is undefined. Kevin
pgpU6EQDyrnKt.pgp
Description: PGP signature
