13.08.2019 17:43, Max Reitz wrote: > 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 <mre...@redhat.com> >>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> >> >> 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. >
Could you tell me at least, what means "allocated" ? It's a term that describing a region somehow.. But how? Allocated where? In raw node, in its child or both? Am I right that if region allocated in one of non-cow children it is assumed to be allocated in parent too? Or what? And it's unrelated to real disk allocation which (IMHO) directly shows that this a bad term. -- Best regards, Vladimir
