Lines Matching +full:data +full:- +full:bits
5 both for actual guest data and for image metadata.
17 Byte 0 - 3: magic
20 4 - 7: version
23 8 - 15: backing_file_offset
28 Note: backing files are incompatible with raw external data
29 files (auto-clear feature bit 1).
31 16 - 19: backing_file_size
36 20 - 23: cluster_bits
37 Number of bits that are used for addressing an offset
48 24 - 31: size
54 beyond 2 EB (61 bits); with a 512 byte cluster
56 larger than 128 GB (37 bits). Meanwhile, L1/L2
58 (56 bits) of populated clusters, and an image may
62 32 - 35: crypt_method
67 36 - 39: l1_size
70 40 - 47: l1_table_offset
74 48 - 55: refcount_table_offset
78 56 - 59: refcount_table_clusters
81 60 - 63: nb_snapshots
84 64 - 71: snapshots_offset
92 72 - 79: incompatible_features
101 Bit 1: Corrupt bit. If this bit is set then any data
106 Bit 2: External data file bit. If this bit is set, an
107 external data file is used. Guest clusters are
108 then stored in the external data file. For such
109 images, clusters in the external data file are
115 An External Data File Name header extension may
119 a non-default compression is used for compressed
125 allows subcluster-based allocation. See the
128 Bits 5-63: Reserved (set to 0)
130 80 - 87: compatible_features
132 safely ignore any unknown bits that are set.
139 Bits 1-63: Reserved (set to 0)
141 88 - 95: autoclear_features
142 Bitmask of auto-clear features. An implementation may only
143 write to an image with unknown auto-clear features if it
144 clears the respective bits from this field first.
148 extension data.
154 bit is unset, the bitmaps extension data must be
157 Bit 1: Raw external data bit
158 If this bit is set, the external data file can
164 zeros requires writing to the data file instead
168 This bit may only be set if the External Data
172 Bits 2-63: Reserved (set to 0)
174 96 - 99: refcount_order
176 in bits: refcount_bits = 1 << refcount_order). For version 2
181 100 - 103: header_length
199 2. If there are no unrecognized incompatible feature bits set, an unknown
217 must be present and non-zero (which means non-deflate
229 105 - 111: Padding, contents defined below.
245 Byte 0 - 3: Header extension type:
246 0x00000000 - End of the header extension area
247 0xe2792aca - Backing file format name string
248 0x6803f857 - Feature name table
249 0x23852875 - Bitmaps extension
250 0x0537be77 - Full disk encryption header pointer
251 0x44415441 - External data file name string
252 other - Unknown header extension, can be safely
255 4 - 7: Length of the header extension data
257 8 - n: Header extension data
259 n - m: Padding to round up the header extension size to the next
267 the first cluster. It is not allowed to store other data here, so that an
269 data of compatible features that it doesn't support. Compatible features that
270 need space for additional data can use a header extension.
276 data file name) are just a single string. In this case, the header extension
291 the header extension data. Each entry look like this:
299 values: 0-63)
301 2 - 47: Feature name (padded with zeros, but not necessarily null
312 The data of the extension should be considered consistent only if the
313 corresponding auto-clear feature bit is set, see autoclear_features above.
317 Byte 0 - 3: nb_bitmaps
324 4 - 7: Reserved, must be zero.
326 8 - 15: bitmap_directory_size
330 16 - 23: bitmap_directory_offset
342 its additional data, as well as the length of such data.
344 Byte 0 - 7: Offset into the image file at which the encryption
347 Byte 8 - 15: Length of the written encryption header in bytes.
357 partition header. This is then followed by the key material data areas.
358 The size of the key material data areas is determined by the number of
360 specification ('docs/on-disk-format.pdf' in the cryptsetup source
363 In the LUKS partition header, the "payload-offset" field will be
372 In the LUKS key slots header, the "key-material-offset" is relative
378 +-----------------------------+
384 +-----------------------------+
388 +-----------------------------+
389 | +-------------------------+ |
391 | +-------------------------+ |
393 | +-------------------------+ |
395 | +-------------------------+ |
397 | +-------------------------+ |
399 | +-------------------------+ |
400 +-----------------------------+
406 +-----------------------------+
408 == Data encryption ==
411 data must be encrypted/decrypted on every write/read. The image headers
416 - AES:
426 and data liberation.
428 - LUKS:
443 The refcounts are managed in a two-level table. The first level is called
452 (56 bits) (assuming the underlying protocol can even be sized that
458 4, it is unable to reference host resources beyond 2 EB (61 bits); in
460 unable to access beyond 32 GB (35 bits).
475 Bit 0 - 8: Reserved (set to 0)
477 9 - 63: Bits 9-63 of the offset into the image file at which the
485 Refcount block entry (x = refcount_bits - 1):
487 Bit 0 - x: Reference count of the cluster. If refcount_bits implies a
488 sub-byte width, note that bit 0 means the least significant
494 Just as for refcounts, qcow2 uses a two-level structure for the mapping of
504 cluster must currently map to a host offset below 64 PB (56 bits)
505 (although this limit could be relaxed by putting reserved bits into
508 compressed clusters to reside below 512 TB (49 bits), and this limit
528 Bit 0 - 8: Reserved (set to 0)
530 9 - 55: Bits 9-55 of the offset into the image file at which the L2
535 56 - 62: Reserved (set to 0)
543 Bit 0 - 61: Cluster descriptor
553 With external data files, all guest clusters have an
562 but it won't be used for reading data from this cluster,
563 nor is data read from the backing file if the cluster is
569 1 - 8: Reserved (set to 0)
571 9 - 55: Bits 9-55 of host cluster offset. Must be aligned to a
575 external data file is used.
577 56 - 61: Reserved (set to 0)
580 Compressed Clusters Descriptor (x = 62 - (cluster_bits - 8)):
582 Bit 0 - x-1: Host cluster offset. This is usually _not_ aligned to a
584 small enough that this field includes bits beyond
585 55, those upper bits must be set to 0.
587 x - 61: Number of additional 512-byte sectors used for the
588 compressed data, beyond the sector containing the offset
592 Note that the compressed data does not necessarily occupy
594 stops when it has produced a cluster of data.
599 If a cluster is unallocated, read requests shall read the data from the backing
609 In these images standard data clusters are divided into 32 subclusters of the
612 indicating the status of each one of them. Compressed data clusters don't have
615 The size of an extended L2 entry is 128 bits so the number of entries per table
620 The first 64 bits have the same format as the standard L2 table entry described
624 The last 64 bits contain a subcluster allocation bitmap with this format:
628 Bit 0 - 31: Allocation status (one bit per subcluster)
635 return zeros if there is no backing file data.
637 Bits are assigned starting from the least significant
640 32 - 63 Subcluster reads as zeros (one bit per subcluster)
647 Bits are assigned starting from the least significant
648 one (i.e. bit x is used for subcluster x - 32).
652 Bit 0 - 63: Reserved (set to 0)
673 have variable length, depending on the length of ID, name and extra data.
677 Byte 0 - 7: Offset into the image file at which the L1 table for the
680 8 - 11: Number of entries in the L1 table of the snapshots
682 12 - 13: Length of the unique ID string describing the snapshot
684 14 - 15: Length of the name of the snapshot
686 16 - 19: Time at which the snapshot was taken in seconds since the
689 20 - 23: Subsecond part of the time at which the snapshot was taken
692 24 - 31: Time that the guest was running until the snapshot was
695 32 - 35: Size of the VM state in bytes. 0 if no VM state is saved.
702 36 - 39: Size of extra data in the table entry (used for future
705 variable: Extra data for future extensions. Unknown fields must be
709 Byte 40 - 47: Size of the VM state in bytes. 0 if no VM
711 the 32-bit value in bytes 32-35 is ignored.
713 Byte 48 - 55: Virtual disk size of the snapshot in bytes
715 Byte 56 - 63: icount value which corresponds to
717 when the snapshot was taken. Set to -1
720 Version 3 images must include extra data at least up to
742 [bit_nr * bitmap_granularity .. (bit_nr + 1) * bitmap_granularity - 1]
753 length, depending on the lengths of the bitmap name and extra data.
757 Byte 0 - 7: bitmap_table_offset
762 8 - 11: bitmap_table_size
765 12 - 15: flags
770 well-formed from a qcow2 perspective, the metadata
771 (such as the auto flag or bitmap size) or data
781 This flags is meaningful when the extra data is
782 unknown to the software (currently any extra data is
785 data must be left as is.
787 both it and its extra data be left as is.
789 Bits 3 - 31 are reserved and must be 0.
796 Values 0, 2 - 255 are reserved.
799 Granularity bits. Valid values: 0 - 63.
801 Note: QEMU currently supports only values 9 - 31.
809 18 - 19: name_size
810 Size of the bitmap name. Must be non-zero.
815 20 - 23: extra_data_size
816 Size of type-specific extra data.
818 For now, as no extra data is defined, extra_data_size is
819 reserved and should be zero. If it is non-zero the
823 Extra data for the bitmap, occupying extra_data_size bytes.
824 Extra data must never contain references to clusters or in
838 Each bitmap is stored using a one-level structure (as opposed to two-level
840 bitmap data to host clusters. This structure is called the bitmap table.
848 Bit 0: Reserved and must be zero if bits 9 - 55 are non-zero.
849 If bits 9 - 55 are zero:
853 1 - 8: Reserved and must be zero.
855 9 - 55: Bits 9 - 55 of the host cluster offset. Must be aligned to
860 56 - 63: Reserved and must be zero.
863 === Bitmap data ===
865 As noted above, bitmap data is stored in separate clusters, described by the
866 bitmap table. Given an offset (in bytes) into the bitmap data, the offset into
873 This offset is not defined if bits 9 - 55 of bitmap table entry are zero (see
884 If the size of the bitmap data is not a multiple of the cluster size then the
885 last cluster of the bitmap data contains some unused tail bits. These bits must