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

[Yaniv Lavi (Dary)]

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

address@hidden    T: +972-9-7692306/8272306     F: +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 <address@hidden> 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.
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
>