qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH 18/19] [RFC] Possible qcow2 specification extensions


From: Kevin Wolf
Subject: [Qemu-devel] [PATCH 18/19] [RFC] Possible qcow2 specification extensions
Date: Thu, 12 Apr 2012 17:01:19 +0200

This contains the changes that were part of the first version 3
specification RFC, but aren't implemented by qemu yet. They are not
meant to become official yet.

Changes implemented in this RFC:

- Added a dirty flag which tells that the refcount may not be accurate ("QED
  mode"). This means that we can save writes to the refcount table with
  cache=writethrough, but isn't really useful otherwise since Qcow2Cache.

- Added subclusters. This separate the COW size (one subcluster, I'm thinking
  of 64k default size here) from the allocation size (one cluster, 2M). Less
  fragmentation, less metadata, but still reasonable COW granularity.

  This also allows to preallocate clusters, but none of their subclusters. You
  can have an image that is like raw + COW metadata, and you can also
  preallocate metadata for images with backing files.

Possible future additions:

- Add per-L2-table dirty flag to L1?
- Add per-refcount-block full flag to refcount table?
---
 docs/specs/qcow2.txt |   23 +++++++++++++++++++++--
 1 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
index 00c5696..13fc5a9 100644
--- a/docs/specs/qcow2.txt
+++ b/docs/specs/qcow2.txt
@@ -75,7 +75,14 @@ in the description of a field.
                     Bitmask of incompatible features. An implementation must
                     fail to open an image if an unknown bit is set.
 
-                    Bits 0-63:  Reserved (set to 0)
+                    Bit 0:      The reference counts in the image file may be
+                                inaccurate. Implementations must check/rebuild
+                                them if they rely on them.
+
+                    Bit 1:      Enable subclusters. This affects the L2 table
+                                format.
+
+                    Bits 2-63:  Reserved (set to 0)
 
          80 -  87:  compatible_features
                     Bitmask of compatible features. An implementation can
@@ -200,7 +207,8 @@ guest clusters to host clusters. They are called L1 and L2 
table.
 
 The L1 table has a variable size (stored in the header) and may use multiple
 clusters, however it must be contiguous in the image file. L2 tables are
-exactly one cluster in size.
+exactly one cluster in size if subclusters are disabled, and two clusters if
+they are enabled.
 
 Given a offset into the virtual disk, the offset into the image file can be
 obtained as follows:
@@ -242,6 +250,17 @@ L2 table entry:
                     in L2 tables that are reachable from the the active L1
                     table.
 
+        64 - 127:   If subclusters are enabled, this contains a bitmask that
+                    describes the allocation status of all 32 subclusters (two
+                    bits for each). The first subcluster is represented by the
+                    LSB. The values for each subcluster are:
+
+                     0: Subcluster is unallocated
+                     1: Subcluster is allocated
+                     2: Subcluster is unallocated and reads as all zeros
+                        instead of referring to the backing file
+                     3: Reserved
+
 Standard Cluster Descriptor:
 
     Bit       0:    If set to 1, the cluster reads as all zeros. The host
-- 
1.7.6.5




reply via email to

[Prev in Thread] Current Thread [Next in Thread]