|
From: | Yaniv Lavi (Dary) |
Subject: | Re: [Qemu-block] [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
34 Jerusalem Road, Building A, 1st floor
Ra'anana, Israel 4350109
address@hidden T: +972-9-7692306/8272306 F: +972-9-7692223 IM: ylavi
TRIED. TESTED. TRUSTED. |
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
Using raw layout for the data in a qcow2 file would give you exactly the> <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.
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
>
>
[Prev in Thread] | Current Thread | [Next in Thread] |