Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3335 bytes --]

On 2017-08-29 11:26, Yaniv Lavi (Dary) wrote:
> 
> 
> YANIV LAVI (YANIV DARY)
> 
> SENIOR TECHNICAL PRODUCT MANAGER
> 
> Red Hat Israel Ltd. <https://www.redhat.com/>
> 
> 34 Jerusalem Road, Building A, 1st floor
> 
> Ra'anana, Israel 4350109
> 
> ylavi@redhat.com <mailto:ylavi@redhat.com>    T: +972-9-7692306
> <tel:+972-9-7692306>/8272306 <tel:8272306>     F: +972-9-7692223
> <tel:+972-9-7692223>    IM: ylavi
> 
> <https://red.ht/sig>	TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> 
> @redhatnews <https://twitter.com/redhatnews>   Red Hat
> <https://www.linkedin.com/company/red-hat>   Red Hat
> <https://www.facebook.com/RedHatInc>
> 
> 
> On Mon, Aug 28, 2017 at 9:11 PM, John Snow <jsnow@redhat.com
> <mailto:jsnow@redhat.com>> wrote:
> 
> 
> 
>     On 08/27/2017 10:57 PM, Fam Zheng wrote:
>     > On Fri, 08/25 15:44, Max Reitz wrote:
>     >> Well, OK.  The main argument against supporting anything but qcow2 is
>     >> "if you want features, use qcow2; and we are working on making
>     qcow2 as
>     >> fast as possible."  I think that's a very good argument still. 
>     At some
>     >> point I (and probably others, too) had the idea of making qcow2
>     files in
>     >> raw layout:
>     >
>     >
>     > Yes! I think this idea makes a whole lot of sense, too. Metadata
>     tables can be
>     > generated so old implementation can still use it.
>     >
>     > Fam
>     >
>     >> Have the data as a blob, just like a raw file, padded by
>     >> metadata around it.  An autoclear flag would specify that the
>     qcow2 file
>     >> is in this format, and if so, you could simply access it like a
>     raw file
>     >> and should have exactly the same speed as a raw file.  Maybe that
>     would
>     >> solve this whole issue, too?
> 
>     I wonder if this would be sufficient to alleviate the desire to use raw
>     files...
> 
>     (Eh, well, realistically, someone's still always going to ask if they
>     can use various features with non-qcow2 files...)
> 
>     Nir, Yaniv; any input?
> 
> 
> We are using raw format for performance reasons.

Using raw layout for the data in a qcow2 file would give you exactly the
same performance as raw.

(Or better "should", but I can't think of a reason why it would not.)

Max

> As we have many customers that currently use this format, not support it
> would be a blocker the use of the feature.
> At a minimum we would require ability to convert raw to qcow2 raw-layout.
> 
> Please also consider that we are planning to go on the OSP route of LUN
> per disk and would still want the tracking to work.
> I makes sense that for that and raw format you will be able to save the
> mapping to another file other than a qcow.
>  
> 
> 
>     (Context: We're debating how to add persistent bitmaps to raw files as I
>     was informed that RHV was 'asking about it.' Max is reminding me there
>     is a proposal for a style of QCOW2 that uses a raw layout for data,
>     mitigating or eliminating any performance hits related to the L2 cache.
>     What I am not aware of is why RHV would use raw files for any purpose.
>     Is it performance? Simplicity? Could RHV use a raw-layout qcow2?)
> 
>     --js
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]