On Fri 09 Dec 2016 03:21:08 PM CET, Max Reitz wrote:
In some scenarios, however, there's a different alternative: if the
qcow2 image is stored in a slow backend (eg. HDD), we could save
memory by putting the L2 cache in a faster one (SSD) instead of in
RAM.
Well, from a full design standpoint, it doesn't make a lot of sense to
me:
We have a two-level on-disk structure for cluster mapping so as to not
waste memory for unused areas and so that we don't need to keep one
large continuous chunk of metadata. Accessing the disk is slow, so we
also have an in-memory cache which is just a single level fully
associative cache replicating the same data (but just a part of it).
Now you want to replicate all of it and store it on disk. My mind
tells me that is duplicate data: We already have all of the metadata
elsewhere on disk, namely in the qcow2 file, and even better, it is
not stored in a fully associative structure there but directly mapped,
making finding the correct entry much quicker.
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).
However, the thing is that the existing structures also only exist in
the original qcow2 file and cannot be just placed anywhere else, as
opposed to our cache. In order to solve this, we would need to
(incompatibly) modify the qcow2 format to allow storing data
independently from metadata. I think this would be certainly doable,
but the question is whether it is worth the effort.
You mean split the qcow2 file in two: data and metadata? I don't think
it's worth the effort.