On 18/11/14 19:08, John Snow wrote:
On 11/18/2014 08:09 AM, Vladimir Sementsov-Ogievskiy wrote:
(3) Data Integrity
The dirty flag could work something like:
- If, on first open, the file has the dirty flag set, we need to
discard the bitmap data because we can no longer trust it.
- If the bi
On 11/18/2014 08:09 AM, Vladimir Sementsov-Ogievskiy wrote:
(3) Data Integrity
The dirty flag could work something like:
- If, on first open, the file has the dirty flag set, we need to
discard the bitmap data because we can no longer trust it.
- If the bitmap file is clean, proceed as normal
Also, if we sync not the last level, bitmap.dirty_flag should be related
to syncing level, not to the whole bitmap, to reduce sync overhead.
Or, if we implement difficult sync policy, there should be dirty flags
for each bitmap level. Despite this, only one level is needed to be
saved in the bit
(3) Data Integrity
The dirty flag could work something like:
- If, on first open, the file has the dirty flag set, we need to
discard the bitmap data because we can no longer trust it.
- If the bitmap file is clean, proceed as normal, but take a lock
against any of the bitmap functions to prev
(2) File Format
Some standard file magic, which includes:
- Some magic byte(s)
- Dirty flag. Needed to tell if we can trust this data or not.
- The size of the bitmap
- The granularity of the bitmap
- The offset to the first sector of bitmap data (Maybe? It can't hurt
if we give ourselves a s
v6: Rebased v4 of the series on top of qemu.git. (skipping v5 since it was used
by me as a private sending, for those who received it, the code is the same
:)
This is the in memory part of the incremental backup feature.
With the added commands, we can create a bitmap on a block backend,
