Lines Matching full:be
34 Length of the backing file name in bytes. Must not be
41 Must not be less than 9 (i.e. 512 byte clusters).
44 as the maximum cluster size and won't be able to open images
48 must be at least 14 (i.e. 16384 byte clusters).
74 starts. Must be aligned to a cluster boundary.
78 starts. Must be aligned to a cluster boundary.
88 starts. Must be aligned to a cluster boundary.
100 may be inconsistent, make sure to scan L1/L2
105 structure may be corrupt and the image must not
106 be written to (unless for regaining
119 be present if this bit is set.
123 clusters. The compression_type field must be
138 lazy refcount updates can be used. This means
157 bit is unset, the bitmaps extension data must be
162 be read as a consistent standalone raw image
171 This bit may only be set if the External Data
180 images, the order is always assumed to be 4
186 images, the length is always assumed to be 72 bytes.
187 For version 3 it's at least 104 bytes and must be a multiple
194 In general, these fields are optional and may be safely ignored by the software,
199 1. If the value of the additional field must not be ignored for correct
200 handling of the file, it will be accompanied by a corresponding incompatible
204 additional field may be safely ignored other than preserving its value when
225 must be present and non-zero (which means non-deflate
226 compression type). Otherwise, this field must not be present
227 or must be zero (which means deflate).
242 ``header_length`` must be a multiple of 8, which means that if the end of the last
243 additional field is not aligned, some padding is needed. This padding must be
245 the padding, it will be interpreted accordingly to point `[3.] <#ref_rules_3>`_ of the previous
253 be stored. Each extension has a structure like the following::
262 other - Unknown header extension, can be safely
275 If the image has a backing file then the backing file name should be stored in
298 for features used by the image. It can be used by applications that don't know
325 The data of the extension should be considered consistent only if the
331 The number of bitmaps contained in the image. Must be
337 4 - 7: Reserved, must be zero.
345 starts. Must be aligned to a cluster boundary.
350 The full disk encryption header must be present if, and only if, the
352 of the ``LUKS`` crypt method. The header extension must be absent for
360 header starts in bytes. Must be aligned to a cluster
364 be larger than this value, since it will be rounded
366 unused bytes in the allocated space will be initialized
378 In the LUKS partition header, the ``payload-offset`` field will be
381 start of the LUKS header. This offset value is not required to be
385 should always be present.
428 data must be encrypted/decrypted on every write/read. The image headers
463 refcount table can cover multiple clusters, however it needs to be contiguous
470 (56 bits) (assuming the underlying protocol can even be sized that
481 Given an offset into the image file, the refcount of its cluster can be
497 refcount block starts. Must be aligned to a cluster
518 clusters, however it must be contiguous in the image file. L2 tables are
525 (although this limit could be relaxed by putting reserved bits into
529 cannot be relaxed without an incompatible layout change).
531 Given an offset into the virtual disk, the offset into the image file can be
551 table starts. Must be aligned to a cluster boundary. If the
575 mapping for guest cluster offsets), so this bit should be 1
581 cluster offset can be used to describe a preallocation,
582 but it won't be used for reading data from this cluster,
591 9 - 55: Bits 9-55 of host cluster offset. Must be aligned to a
593 the cluster is unallocated. The offset may only be 0 with
605 55, those upper bits must be set to 0.
632 Subclusters can be allocated independently and the L2 entry contains information
666 allocation status bit must be unset. The host
667 cluster offset field may or may not be set.
686 When creating a snapshot, the L1 table should be copied and the refcount of all
687 L2 tables and clusters reachable from this L1 table must be increased, so that
691 all L2 tables referenced by it must be reconstructed from the refcount table
692 as it doesn't need to be accurate in inactive L1 tables.
702 snapshot starts. Must be aligned to a cluster boundary.
729 variable: Extra data for future extensions. Unknown fields must be
765 disk. For bit number bit_nr the corresponding range (in bytes) will be:
787 (described below) for the bitmap starts. Must be aligned to
796 The bitmap was not saved correctly and may be
800 contents may be outdated.
806 type of this bitmap must be 'dirty tracking bitmap'.
812 If it is set, the bitmap may be used as expected, extra
813 data must be left as is.
814 If it is not set, the bitmap must not be used, but
815 both it and its extra data be left as is.
817 Bits 3 - 31 are reserved and must be 0.
838 Size of the bitmap name. Must be non-zero.
847 reserved and should be zero. If it is non-zero the
857 name_size bytes. Must be unique among all bitmap names
861 next multiple of 8. All bytes of the padding must be zero.
872 and may use multiple clusters, however, it must be contiguous in the image
877 Bit 0: Reserved and must be zero if bits 9 - 55 are non-zero.
879 0: Cluster should be read as all zeros.
880 1: Cluster should be read as all ones.
882 1 - 8: Reserved and must be zero.
884 9 - 55: Bits 9 - 55 of the host cluster offset. Must be aligned to
887 cluster should be treated during reads.
889 56 - 63: Reserved and must be zero.
897 the image file can be obtained as follows::
907 bit offset into the image file to the corresponding bit of the bitmap can be
916 be zero.
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
932 should be set while the bitmap is not synced.