Lines Matching +full:data +full:- +full:bits
7 both for actual guest data and for image metadata.
15 ------
19 Byte 0 - 3: magic
22 4 - 7: version
25 8 - 15: backing_file_offset
30 Note: backing files are incompatible with raw external data
31 files (auto-clear feature bit 1).
33 16 - 19: backing_file_size
38 20 - 23: cluster_bits
39 Number of bits that are used for addressing an offset
50 24 - 31: size
56 beyond 2 EB (61 bits); with a 512 byte cluster
58 larger than 128 GB (37 bits). Meanwhile, L1/L2
60 (56 bits) of populated clusters, and an image may
64 32 - 35: crypt_method
69 36 - 39: l1_size
72 40 - 47: l1_table_offset
76 48 - 55: refcount_table_offset
80 56 - 59: refcount_table_clusters
83 60 - 63: nb_snapshots
86 64 - 71: snapshots_offset
95 72 - 79: incompatible_features
104 Bit 1: Corrupt bit. If this bit is set then any data
109 Bit 2: External data file bit. If this bit is set, an
110 external data file is used. Guest clusters are
111 then stored in the external data file. For such
112 images, clusters in the external data file are
118 An External Data File Name header extension may
122 a non-default compression is used for compressed
128 allows subcluster-based allocation. See the
131 Bits 5-63: Reserved (set to 0)
133 80 - 87: compatible_features
135 safely ignore any unknown bits that are set.
142 Bits 1-63: Reserved (set to 0)
144 88 - 95: autoclear_features
145 Bitmask of auto-clear features. An implementation may only
146 write to an image with unknown auto-clear features if it
147 clears the respective bits from this field first.
151 extension data.
157 bit is unset, the bitmaps extension data must be
160 Bit 1: Raw external data bit
161 If this bit is set, the external data file can
167 zeros requires writing to the data file instead
171 This bit may only be set if the External Data
175 Bits 2-63: Reserved (set to 0)
177 96 - 99: refcount_order
179 in bits: refcount_bits = 1 << refcount_order). For version 2
184 100 - 103: header_length
192 ----------------------------------------
203 2. If there are no unrecognized incompatible feature bits set, an unknown
225 must be present and non-zero (which means non-deflate
230 - 0: deflate <https://www.ietf.org/rfc/rfc1951.txt>
231 - 1: zstd <http://github.com/facebook/zstd>
237 105 - 111: Padding, contents defined below.
240 --------------
250 -----------------
255 Byte 0 - 3: Header extension type:
256 0x00000000 - End of the header extension area
257 0xe2792aca - Backing file format name string
258 0x6803f857 - Feature name table
259 0x23852875 - Bitmaps extension
260 0x0537be77 - Full disk encryption header pointer
261 0x44415441 - External data file name string
262 other - Unknown header extension, can be safely
265 4 - 7: Length of the header extension data
267 8 - n: Header extension data
269 n - m: Padding to round up the header extension size to the next
277 the first cluster. It is not allowed to store other data here, so that an
279 data of compatible features that it doesn't support. Compatible features that
280 need space for additional data can use a header extension.
284 ------------------------
287 data file name) are just a single string. In this case, the header extension
295 ------------------
303 the header extension data. Each entry looks like this::
311 values: 0-63)
313 2 - 47: Feature name (padded with zeros, but not necessarily null
318 -----------------
325 The data of the extension should be considered consistent only if the
326 corresponding auto-clear feature bit is set, see ``autoclear_features`` above.
330 Byte 0 - 3: nb_bitmaps
337 4 - 7: Reserved, must be zero.
339 8 - 15: bitmap_directory_size
343 16 - 23: bitmap_directory_offset
348 -----------------------------------
356 its additional data, as well as the length of such data.
359 Byte 0 - 7: Offset into the image file at which the encryption
362 Byte 8 - 15: Length of the written encryption header in bytes.
372 partition header. This is then followed by the key material data areas.
373 The size of the key material data areas is determined by the number of
375 specification (``docs/on-disk-format.pdf`` in the cryptsetup source
378 In the LUKS partition header, the ``payload-offset`` field will be
387 In the LUKS key slots header, the ``key-material-offset`` is relative
394 +-----------------------------+
400 +-----------------------------+
404 +-----------------------------+
405 | +-------------------------+ |
407 | +-------------------------+ |
409 | +-------------------------+ |
411 | +-------------------------+ |
413 | +-------------------------+ |
415 | +-------------------------+ |
416 +-----------------------------+
422 +-----------------------------+
424 Data encryption
425 ---------------
428 data must be encrypted/decrypted on every write/read. The image headers
433 - ``AES``:
443 and data liberation.
445 - ``LUKS``:
454 -----------------------
461 The refcounts are managed in a two-level table. The first level is called
470 (56 bits) (assuming the underlying protocol can even be sized that
477 4, it is unable to reference host resources beyond 2 EB (61 bits); in
479 unable to access beyond 32 GB (35 bits).
494 Bit 0 - 8: Reserved (set to 0)
496 9 - 63: Bits 9-63 of the offset into the image file at which the
504 Refcount block entry ``(x = refcount_bits - 1)``::
506 Bit 0 - x: Reference count of the cluster. If refcount_bits implies a
507 sub-byte width, note that bit 0 means the least significant
512 ---------------
514 Just as for refcounts, qcow2 uses a two-level structure for the mapping of
524 cluster must currently map to a host offset below 64 PB (56 bits)
525 (although this limit could be relaxed by putting reserved bits into
528 compressed clusters to reside below 512 TB (49 bits), and this limit
548 Bit 0 - 8: Reserved (set to 0)
550 9 - 55: Bits 9-55 of the offset into the image file at which the L2
555 56 - 62: Reserved (set to 0)
563 Bit 0 - 61: Cluster descriptor
573 With external data files, all guest clusters have an
582 but it won't be used for reading data from this cluster,
583 nor is data read from the backing file if the cluster is
589 1 - 8: Reserved (set to 0)
591 9 - 55: Bits 9-55 of host cluster offset. Must be aligned to a
595 external data file is used.
597 56 - 61: Reserved (set to 0)
600 Compressed Clusters Descriptor ``(x = 62 - (cluster_bits - 8))``::
602 Bit 0 - x-1: Host cluster offset. This is usually _not_ aligned to a
604 small enough that this field includes bits beyond
605 55, those upper bits must be set to 0.
607 x - 61: Number of additional 512-byte sectors used for the
608 compressed data, beyond the sector containing the offset
612 Note that the compressed data does not necessarily occupy
614 stops when it has produced a cluster of data.
619 If a cluster is unallocated, read requests shall read the data from the backing
625 -------------------
630 In these images standard data clusters are divided into 32 subclusters of the
633 indicating the status of each one of them. Compressed data clusters don't have
636 The size of an extended L2 entry is 128 bits so the number of entries per table
643 The first 64 bits have the same format as the standard L2 table entry described
647 The last 64 bits contain a subcluster allocation bitmap with this format:
651 Bit 0 - 31: Allocation status (one bit per subcluster)
658 return zeros if there is no backing file data.
660 Bits are assigned starting from the least significant
663 32 - 63 Subcluster reads as zeros (one bit per subcluster)
670 Bits are assigned starting from the least significant
671 one (i.e. bit x is used for subcluster x - 32).
675 Bit 0 - 63: Reserved (set to 0)
680 ---------
697 have variable length, depending on the length of ID, name and extra data.
701 Byte 0 - 7: Offset into the image file at which the L1 table for the
704 8 - 11: Number of entries in the L1 table of the snapshots
706 12 - 13: Length of the unique ID string describing the snapshot
708 14 - 15: Length of the name of the snapshot
710 16 - 19: Time at which the snapshot was taken in seconds since the
713 20 - 23: Subsecond part of the time at which the snapshot was taken
716 24 - 31: Time that the guest was running until the snapshot was
719 32 - 35: Size of the VM state in bytes. 0 if no VM state is saved.
726 36 - 39: Size of extra data in the table entry (used for future
729 variable: Extra data for future extensions. Unknown fields must be
733 Byte 40 - 47: Size of the VM state in bytes. 0 if no VM
735 the 32-bit value in bytes 32-35 is ignored.
737 Byte 48 - 55: Virtual disk size of the snapshot in bytes
739 Byte 56 - 63: icount value which corresponds to
741 when the snapshot was taken. Set to -1
744 Version 3 images must include extra data at least up to
756 -------
769 [bit_nr * bitmap_granularity .. (bit_nr + 1) * bitmap_granularity - 1]
775 ----------------
781 length, depending on the lengths of the bitmap name and extra data.
785 Byte 0 - 7: bitmap_table_offset
790 8 - 11: bitmap_table_size
793 12 - 15: flags
798 well-formed from a qcow2 perspective, the metadata
799 (such as the auto flag or bitmap size) or data
809 This flags is meaningful when the extra data is
810 unknown to the software (currently any extra data is
813 data must be left as is.
815 both it and its extra data be left as is.
817 Bits 3 - 31 are reserved and must be 0.
824 Values 0, 2 - 255 are reserved.
827 Granularity bits. Valid values: 0 - 63.
829 Note: QEMU currently supports only values 9 - 31.
837 18 - 19: name_size
838 Size of the bitmap name. Must be non-zero.
843 20 - 23: extra_data_size
844 Size of type-specific extra data.
846 For now, as no extra data is defined, extra_data_size is
847 reserved and should be zero. If it is non-zero the
851 Extra data for the bitmap, occupying extra_data_size bytes.
852 Extra data must never contain references to clusters or in
865 ------------
867 Each bitmap is stored using a one-level structure (as opposed to two-level
869 bitmap data to host clusters. This structure is called the bitmap table.
877 Bit 0: Reserved and must be zero if bits 9 - 55 are non-zero.
878 If bits 9 - 55 are zero:
882 1 - 8: Reserved and must be zero.
884 9 - 55: Bits 9 - 55 of the host cluster offset. Must be aligned to
889 56 - 63: Reserved and must be zero.
892 Bitmap data
893 -----------
895 As noted above, bitmap data is stored in separate clusters, described by the
896 bitmap table. Given an offset (in bytes) into the bitmap data, the offset into
903 This offset is not defined if bits 9 - 55 of bitmap table entry are zero (see
914 If the size of the bitmap data is not a multiple of the cluster size then the
915 last cluster of the bitmap data contains some unused tail bits. These bits must
920 ----------------------