On Wed, 02/03 20:16, Vladimir Sementsov-Ogievskiy wrote:
On 03.02.2016 17:41, Fam Zheng wrote:
On Wed, 02/03 16:45, Vladimir Sementsov-Ogievskiy wrote:
Also current scheme is made like one for snapshots.
Okay, then I'll be fine with being consistent.
+
+
+=== Bitmap table ===
+
+Bitmaps are stored using a one-level structure (as opposed to two-level
+structure like for refcounts and guest clusters mapping) for the mapping of
s/structure/structures/
+bitmap data to host clusters. This structure is called the bitmap table.
+
+Each bitmap table has a variable size (stored in the bitmap directory entry)
+and may use multiple clusters, however, it must be contiguous in the image
+file.
+
+Structure of a bitmap table entry:
+
+ Bit 0: Reserved and must be zero if bits 9 - 55 are non-zero.
+ If bits 9 - 55 are zero:
+ 0: Cluster should be read as all zeros.
+ 1: Cluster should be read as all ones.
Once bits 9 - 55 are non-zero, this bit goes useless? That doesn't make much
sense to me. In which case bit 0 is set but 9-55 are zero?
In case "1: Cluster should be read as all ones.".
I cannot think of a use case leading to this.
Why not? It is the dirty bitmap. It may be very dirty, it even may
be all-ones.
I see what this is about. This assumes the bitmap is only saved when the image
is closed, so that if by that time the whole chunk is all-one, this bit is set
without allocating the cluster.
But again, I don't think that is the only way to save bitmap: an implementation
can save dirty bit much more frequently (to free memory), or even do it
synchronously (to be power failure proof). In these cases, this bit is hard to
use, because it's very unlikely all bits are dirtied between two adjacent
saving points.
Sorry for asking for this so late, what about making bit 0 and the offset
orthogonal?
Bits[9..55] = 0 | Bits[9..55] != 0
Bit[0] = 0 zero | read
Bit[0] = 1 one | one