On 2015-02-11 at 12:54, John Snow wrote:
On 02/11/2015 12:47 PM, Max Reitz wrote:
Looks good to me in general, now I need to find out what the successor
bitmap is used for; but I guess I'll find that out by reviewing the rest
of this series.
Max
They don't really come up again, actually.
The basic idea is this: While the backup is going on, reads and writes
may occur (albeit delayed) and we want to track those writes in a
separate bitmap for the duration of the backup operation.
Yes, I thought as much; but where are writes to the named bitmap being
redirected to its successor? bdrv_set_dirty() doesn't do that, as far as
I can see.
If the backup operation fails, we use the dirty sector tracking info
in the successor to know what has changed since we started the backup,
and we merge this bitmap back into the originating bitmap; then if an
incremental backup is tried again, it includes all of the original
data plus any data changed while we failed to do a backup.
If the backup operation succeeds, the originating bitmap is deleted
and the successor is installed in its place.
It's a namespace trick: by having an anonymous bitmap as a child of
the "real" bitmap, the real bitmap can be frozen and prohibited from
being moved, renamed, deleted, etc. This prevents the user from adding
a new bitmap with the same name or similar while the backup is in
progress.
Hm, if it's just for that, wouldn't disabling the bitmap suffice?
Max
A previous approach was to immediately take the bitmap off of the BDS,
but in the error case here, the logic becomes more complicated when we
need to re-install the bitmap but the user has already installed a new
bitmap with the same name, etc.
So the general lifetime is this:
(1) A backup is started. the block/backup routine calls create_successor.
(2) If the backup fails to start, the block/backup routine will call
the "reclaim" method, which will merge the (empty) successor back into
the original bitmap, unfreezing it.
(3) If the backup starts, and then fails, the bitmap is "reclaim"ed
(merged back into one bitmap.)
(4) If the backup succeeds, the bitmap "abdicates" to the successor.
(The parent bitmap is erased and the successor is installed in its
place.)
Yes, see the graph at the whiteboard behind me. :-)
Max