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. (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 > >
signature.asc
Description: OpenPGP digital signature
