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. Kevin
