Re: [Qemu-devel] [PATCH RFC 0/1] Allow storing the qcow2 L2 cache in disk

[Fam Zheng <famz@redhat.com>]

On Tue, 12/13 13:29, Kevin Wolf wrote:
> Am 13.12.2016 um 11:16 hat Fam Zheng geschrieben:
> > On Tue, 12/13 09:02, Max Reitz wrote:
> > > > Yes but the use case is that the qcow2 image is stored in a slow disk,
> > > > so things will be faster if we avoid having to read it too often.
> > > > 
> > > > But the data is there and it needs to be read, so we have three options:
> > > > 
> > > >   1) Read it everytime we need it. It slows things down.
> > > >   2) Keep (part of) it in memory. It can use a lot of memory.
> > > >   3) Keep it in a faster disk.
> > > > 
> > > > We're talking about 3) here, and this it not about creating new
> > > > structures, but about changing the storage backend of the existing L2
> > > > cache (disk rather than RAM).
> > > 
> > > I'm arguing that we already have an on-disk L2 structure and that is called
> > > simply the L1-L2 structure in the qcow2 file. The cache only makes sense
> > > because it is in RAM.
> > 
> > I am looking at this problem from a different angle:
> > 
> > Assume a qcow2 image created by a known version of QEMU with the option
> > preallocation=falloc, it is theoretically possible to do a hacky optimization in
> > qcow2 I/O path that, instead of looking up in L1/L2, we can calculate file
> > offset for any given virtual address, by adding the file offset of LBA 0.
> > 
> > If we make this optimization a header extention and add it to the spec, it is no
> > longer a hack, and it should offer nearly the same performance as raw in all
> > cases - if we say raw is doing "identical mapping" from LBA to file offset, this
> > new operation mode of qcow2 file is basically doing a "shift by constant" mapping.
> 
> Is this a scenario that matters in practice, though? If you want
> performance and you don't need COW functionality, just use raw images to
> begin with.

The intention is actually to combine the advantages of both: external snapshot
can be supported by an allocation status bitmap generated from scanning the
whole L1/L2 table, or even from loading a new type of qcow2 bitmap specifically
for making that efficient.

I share the same doubt as Stefan regarding the on disk format. Modern file
systems support sparse file quite well, so I wonder what advantages are still
there in using L1/L2 tables instead of a simple bitmap, if the user doesn't use
internal snapshot in the first place?

Fam