qemu-devel
[Top][All Lists]
Advanced

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

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


From: Yaniv Lavi (Dary)
Subject: Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats
Date: Wed, 30 Aug 2017 15:58:32 +0300

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 Wed, Aug 30, 2017 at 1:35 PM, Max Reitz <address@hidden> wrote:

> 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
> >
> > address@hidden <mailto:address@hidden>    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 <address@hidden
> > <mailto: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.
>
> Using raw layout for the data in a qcow2 file would give you exactly the
> same performance as raw.
>

We had no reason to switch to anything else so far and I'm sure this option
was not available when we started supporting raw format.


>
> (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
> >
> >
>
>
>


reply via email to

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