Lines Matching full:in
5 A ``qcow2`` image file is organized in units of constant size, which are called
6 (host) clusters. A cluster is the unit in which all allocations are done,
12 All numbers in qcow2 are stored in Big Endian byte order.
34 Length of the backing file name in bytes. Must not be
51 Virtual disk size in bytes.
70 Number of entries in the active L1 table
84 Number of snapshots contained in the image
90 For version 2, the header is exactly 72 bytes in length, and finishes here.
111 then stored in the external data file. For such
112 images, clusters in the external data file are
113 not refcounted. The offset field in the
168 of only setting the zero flag in the L2 table
179 in bits: refcount_bits = 1 << refcount_order). For version 2
185 Length of the header structure in bytes. For version 2
194 In general, these fields are optional and may be safely ignored by the software,
221 All compressed clusters in an image use the same compression
234 <https://www.zlib.net/> in QEMU. However, clusters with the
246 paragraph, i.e. in the same manner as when this field is not present.
273 in the same image.
275 If the image has a backing file then the backing file name should be stored in
287 data file name) are just a single string. In this case, the header extension
302 The number of entries in the feature name table is determined by the length of
323 point in time.
331 The number of bitmaps contained in the image. Must be
340 Size of the bitmap directory in bytes. It is the cumulative
360 header starts in bytes. Must be aligned to a cluster
362 Byte 8 - 15: Length of the written encryption header in bytes.
363 Note actual space allocated in the qcow2 file may
366 unused bytes in the allocated space will be initialized
374 stripes in the key slot and key size. Refer to the LUKS format
375 specification (``docs/on-disk-format.pdf`` in the cryptsetup source
378 In the LUKS partition header, the ``payload-offset`` field will be
382 qcow2 cluster aligned. Its value is currently never used in the
387 In the LUKS key slots header, the ``key-material-offset`` is relative
388 to the start of the LUKS header clusters in the qcow2 container,
427 When an encryption method is requested in the header, the image payload
435 The AES cipher, in CBC mode, with 256 bit keys.
440 This format is no longer supported in QEMU system emulators, due
442 supported in the command line tools for the sake of back compatibility
447 The algorithms are specified in the LUKS header.
450 in the LUKS header, with the physical disk sector as the
461 The refcounts are managed in a two-level table. The first level is called
462 refcount table and has a variable size (which is stored in the header). The
464 in the image file.
467 blocks and are exactly one cluster in size.
477 4, it is unable to reference host resources beyond 2 EB (61 bits); in
508 bit in this context.
517 The L1 table has a variable size (stored in the header) and may use multiple
518 clusters, however it must be contiguous in the image file. L2 tables are
519 exactly one cluster in size.
559 in the active L1 table.
570 This information is only accurate in L2 tables
609 in the previous field. Some of these sectors may reside
610 in the next contiguous host cluster.
613 all of the bytes in the final sector; rather, decompression
620 file (except if bit 0 in the Standard Cluster Descriptor is set). If there is
630 In these images standard data clusters are divided into 32 subclusters of the
634 subclusters so they are treated the same as in images without this feature.
644 in the previous section, with the exception of bit 0 of the standard cluster
653 1: the subcluster is allocated. In this case the
656 0: the subcluster is not allocated. In this case
665 1: the subcluster reads as zeros. In this case the
688 a write causes a COW and isn't visible in other snapshots.
690 When loading a snapshot, bit 63 of all entries in the new active L1 table and
692 as it doesn't need to be accurate in inactive L1 tables.
694 A directory of all snapshots is stored in the snapshot table, a contiguous area
695 in the image file, whose starting offset and length are given by the header
704 8 - 11: Number of entries in the L1 table of the snapshots
710 16 - 19: Time at which the snapshot was taken in seconds since the
714 in nanoseconds
717 taken in nanoseconds
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
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
761 All stored bitmaps are related to the virtual disk stored in the same image, so
765 disk. For bit number bit_nr the corresponding range (in bytes) will be:
777 Each bitmap saved in the image is described in a bitmap directory entry. The
778 bitmap directory is a contiguous area in the image file, whose starting offset
791 Number of entries in the bitmap table of the bitmap.
852 Extra data must never contain references to clusters or in
871 Each bitmap table has a variable size (stored in the bitmap directory entry)
872 and may use multiple clusters, however, it must be contiguous in the image
886 unallocated; in that case, bit 0 determines how this
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
924 When the virtual disk is in use dirty tracking bitmap may be ``enabled`` or
926 should be reflected in the bitmap. A set bit in the bitmap means that the
930 The software doesn't have to sync the bitmap in the image file with its
931 representation in RAM after each write or metadata change. Flag ``in_use``
934 In the image file the ``enabled`` state is reflected by the ``auto`` flag. If this