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 Mon, Aug 28, 2017 at 9:11 PM, John Snow <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. 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 >
