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 yl...@redhat.com 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 <mre...@redhat.com> 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 > > > > yl...@redhat.com <mailto:yl...@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 <js...@redhat.com > > <mailto:js...@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. > 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 > > > > > > >
