[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
> >
> >
>
>
>
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, (continued)
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Vladimir Sementsov-Ogievskiy, 2017/08/23
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Vladimir Sementsov-Ogievskiy, 2017/08/23
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Vladimir Sementsov-Ogievskiy, 2017/08/23
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/24
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Vladimir Sementsov-Ogievskiy, 2017/08/25
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/25
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Fam Zheng, 2017/08/27
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/28
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Yaniv Lavi (Dary), 2017/08/29
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/30
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats,
Yaniv Lavi (Dary) <=
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/30
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Yaniv Lavi (Dary), 2017/08/31
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/28
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Eric Blake, 2017/08/29
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/29
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/30
- Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/30
Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/23
Re: [Qemu-devel] [Qemu-block] Persistent bitmaps for non-qcow2 formats, Stefan Hajnoczi, 2017/08/30