qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 16/17] qapi: Expose new qcow2 overlap check o


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v4 16/17] qapi: Expose new qcow2 overlap check options
Date: Mon, 04 May 2015 13:39:03 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 05/04/2015 01:15 PM, Max Reitz wrote:
> Expose the two new options for controlling the memory usage of the
> overlap check implementation via QAPI.
> 
> Signed-off-by: Max Reitz <address@hidden>
> ---
>  qapi/block-core.json | 37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 1c17224..99456e6 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -1509,6 +1509,39 @@
>              'mode':  'Qcow2OverlapCheckMode' } }
>  
>  ##
> +# @Qcow2OverlapStructures
> +#
> +# Contains options for controlling the behavior of the metadata overlap
> +# prevention structures.
> +#
> +# The primary structure used for overlap check and prevention is a bitmap
> +# (actually a bytemap) which has one entry per cluster designating the 
> type(s)
> +# of metadata it contains. In order to save memory, there is an RLE-like
> +# representation of this bitmap, too.
> +#
> +# The whole array of clusters is chunked. The RLE representation of one chunk
> +# is converted to the equivalent bitmap whenever a cluster in the chunk is
> +# accessed. The bitmaps are kept for a limited number of chunks (as a 
> cache). On
> +# cache eviction, the bitmap is converted back to RLE again.

Feels a bit verbose at describing the internal representation,
especially if we change the internals at some point in the future.  I'm
more interested that there are two limits at play, and that tuning them
larger may consume more memory but offer better protection on large images.

> +#
> +# @bitmap-size:      #optional size (in bytes) of the bitmap cache, defaults 
> to
> +#                    64 kB
> +#

Any requirement on it being a power of 2, or even a recommendation on
how large or small to make it in relation to an image size?

> +# @total-size-limit: #optional maximum total size (in bytes) of all the 
> metadata

What happens if bitmap-size is larger than total-size-limit?

> +#                    overlap prevention data structures combined; if this 
> limit
> +#                    is exceeded, a QCOW2_OVERLAP_CHECK_MEMORY_LIMIT_REACHED
> +#                    event will be emitted and some parts of the image may no
> +#                    longer be protected against erroneous overwriting of
> +#                    metadata by (meta)data of a different kind. Defaults to
> +#                    SIZE_MAX.
> +#
> +# Since: 2.4
> +##
> +{ 'type': 'Qcow2OverlapStructures',

Rebase conflict with my series that does s/type/struct/

> +  'data': { '*bitmap-size':      'int',
> +            '*total-size-limit': 'int' } }
> +
> +##
>  # @BlockdevOptionsQcow2
>  #
>  # Driver specific block device options for qcow2.
> @@ -1530,6 +1563,9 @@
>  # @overlap-check:         #optional which overlap checks to perform for 
> writes
>  #                         to the image, defaults to 'cached' (since 2.2)
>  #
> +# @overlap-structures:    #optional options for controlling the behavior of 
> the
> +#                         metadata overlap prevention structures (since 2.4)
> +#
>  # @cache-size:            #optional the maximum total size of the L2 table 
> and
>  #                         refcount block caches in bytes (since 2.2)
>  #
> @@ -1548,6 +1584,7 @@
>              '*pass-discard-snapshot': 'bool',
>              '*pass-discard-other': 'bool',
>              '*overlap-check': 'Qcow2OverlapChecks',
> +            '*overlap-structures': 'Qcow2OverlapStructures',
>              '*cache-size': 'int',
>              '*l2-cache-size': 'int',
>              '*refcount-cache-size': 'int' } }
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]