Consistency of dirty bitmap backups

[Adrien G]

Hi,

I'm working on the incremental backup system offered by the dirty bitmap 
solution.
I'm asking myself about the consistency it provides and the fact that dirty 
bitmap seems obscure, related to its current point in time anchor.

Basically we can do a full backup like this:
1/ block-dirty-bitmap-add
2/ drive-backup (sync=full)

Then, we can do an incremental backup like this:
1/ drive-backup (sync=incremental)

This is awesome. But... I'm thinking about the worst case, where QEMU crashes.

Imagine that QEMU crashes between the drive-backup command start and the 
"BLOCK_JOB_COMPLETED" event, but we don't know when.
In that case, we have 2 possible states:
1/ the drive-backup successfully finished and the bitmap referres to the "new" 
point in time.
2/ the drive-backup didn't finished, the image file is not complete and the 
bitmap referres to the "old" point in time.

AFAIK, there is no way to know to which point in time the dirty bitmap is 
linked to.
Did I missed something?
If no, it could be interesting to have a way to identify the point in time of a 
dirty bitmap.

An idea is to have an integer that increments each time a bitmap is moved to a 
new point in time.
Lets say we have this integer named "moves" as part of BlockDirtyInfo ("moves" 
is a bad name but I don't have a better idea right now).

1/ block-dirty-bitmap-add => moves = 0
2/ drive-backup (sync=full) => On BLOCK_JOB_COMPLETED, moves = 1. 
3/ drive-backup (sync=incremental) => On BLOCK_JOB_COMPLETED, moves = 2. 

Now, imagine that QEMU crashes during another drive-backup.
We have two cases:
1/ moves = 3, in that case we know that the bitmap is linked to the new point 
in time and that the image file contains all the data.
2/ moves = 2, in that case we know that the bitmap is linked to the old point 
in time and that the image file is not consistent and should be deleted.

Did I missed a way to get the dirty bitmap point in time anchor?
If no, what do you think about the integer increment idea?

Best,
Adrien