Lines Matching full:this
99 Bit 0: Dirty bit. If this bit is set then refcounts
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
119 be present if this bit is set.
121 Bit 3: Compression type bit. If this bit is set,
126 Bit 4: Extended L2 Entries. If this bit is set then
137 Bit 0: Lazy refcounts bit. If this bit is set then
138 lazy refcount updates can be used. This means
147 clears the respective bits from this field first.
150 This bit indicates consistency for the bitmaps
153 It is an error if this bit is set without the
156 If the bitmaps extension is present but this
161 If this bit is set, the external data file can
165 Setting this bit has a performance impact for
171 This bit may only be set if the External Data
182 This value may not exceed 6 (i.e. refcount_bits = 64).
226 compression type). Otherwise, this field must not be present
243 additional field is not aligned, some padding is needed. This padding must be
246 paragraph, i.e. in the same manner as when this field is not present.
287 data file name) are just a single string. In this case, the header extension
303 the header extension data. Each entry looks like this::
351 ``crypt_method`` header requires metadata. Currently this is only true
355 This header provides the offset at which the crypt method can store
364 be larger than this value, since it will be rounded
372 partition header. This is then followed by the key material data areas.
381 start of the LUKS header. This offset value is not required to be
440 This format is no longer supported in QEMU system emulators, due
500 If this is 0, the corresponding refcount block has not yet
501 been allocated. All refcounts managed by this refcount block
508 bit in this context.
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
544 [*] this changes if Extended L2 Entries are enabled, see next section
552 offset is 0, the L2 table and all clusters described by this
558 refcount is exactly one. This information is only accurate
570 This information is only accurate in L2 tables
575 mapping for guest cluster offsets), so this bit should be 1
582 but it won't be used for reading data from this cluster,
587 section), this is always 0.
602 Bit 0 - x-1: Host cluster offset. This is usually _not_ aligned to a
604 small enough that this field includes bits beyond
617 sector used by this compressed cluster.
634 subclusters so they are treated the same as in images without this feature.
637 is calculated using this formula:
647 The last 64 bits contain a subcluster allocation bitmap with this format:
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
677 so this field is not used.
687 L2 tables and clusters reachable from this L1 table must be increased, so that
734 state is saved. If this field is present,
759 related to a virtual disk. This section describes how these bitmaps are stored.
804 disk by any application that would write to this qcow2
806 type of this bitmap must be 'dirty tracking bitmap'.
809 This flags is meaningful when the extra data is
820 This field describes the sort of the bitmap.
869 bitmap data to host clusters. This structure is called the bitmap table.
886 unallocated; in that case, bit 0 determines how this
903 This offset is not defined if bits 9 - 55 of bitmap table entry are zero (see
908 calculated like this::
928 bitmap was ``enabled``. An unset bit means that this range was not written to.
934 In the image file the ``enabled`` state is reflected by the ``auto`` flag. If this
936 tracking virtual disk changes to this bitmap from the first write to the
937 virtual disk. If this flag is not set then the bitmap is disabled.