On 13.08.19 13:04, Kevin Wolf wrote: > Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben: >> BDRV_BLOCK_RAW makes generic bdrv_co_block_status to fallthrough to >> returned file. But is it correct behavior at all? If returned file >> itself has a backing file, we may report as totally unallocated and >> area which actually has data in bottom backing file. >> >> So, mirroring of qcow2 under raw-format is broken. Which is illustrated >> by following commit with a test. Let's make raw-format behave more >> correctly returning BDRV_BLOCK_DATA. >> >> Suggested-by: Max Reitz >> Signed-off-by: Vladimir Sementsov-Ogievskiy > > After some reading, I think I came to the conclusion that RAW is the > correct thing to do. There is indeed a problem, but this patch is trying > to fix it in the wrong place. > > In the case where the backing file contains some data, and we have a > 'raw' node above the qcow2 overlay node, the content of the respective > block is not defined by the queried backing file layer, so it is > completely correct that bdrv_is_allocated() returns false,like it would > if you queried the qcow2 layer directly. I disagree. The queried backing file layer is the raw node. As I said, in my opinion raw nodes are not filter nodes, neither in behavior (they have an offset option), nor in how they are generally used (as a format). The raw format does not support backing files. Therefore, everything on a raw node is allocated. (That is, like, my opinion.) > If it returned true, we would > copy everything, which isn't right either (the test cases should may add > the qemu-img map output of the target so this becomes visible). It is right. Max