On 12.08.19 18:50, Vladimir Sementsov-Ogievskiy wrote: > 12.08.2019 18:56, Max Reitz wrote: >> On 12.08.19 17:33, Vladimir Sementsov-Ogievskiy wrote: >>> 25.07.2019 18:55, Max Reitz wrote: >>>> vpc is not really a passthrough driver, even when using the fixed >>>> subformat (where host and guest offsets are equal). It should handle >>>> preallocation like all other drivers do, namely by returning >>>> DATA | RECURSE instead of RAW. >>>> >>>> There is no tangible difference but the fact that bdrv_is_allocated() no >>>> longer falls through to the protocol layer. >>> >>> Hmm. Isn't a real bug (fixed by this patch) ? >>> >>> Assume vpc->file is qcow2 with backing, which have "unallocated" region, >>> which is >>> backed by actual data in backing file. >> >> Come on now. >> >>> So, this region will be reported as not allocated and will be skipped by >>> any copying >>> loop using block-status? Is it a bug of BDRV_BLOCK_RAW itself? Or I don't >>> understand >>> something.. >> >> I think what you don’t understand is that if you have a vpc file inside >> of a qcow2 file, you’re doing basically everything wrong. ;-) >> >> But maybe we should drop BDRV_BLOCK_RAW... Does it do anything good for >> us in the raw driver? Shouldn’t it too just return DATA | RECURSE? >> > > And if I have raw driver above qcow2, it will not work, like I've described > above..
Yep. That’s why I was wondering. (This is a more likely case, because maybe you really want to use raw’s offset capability on top of qcow2.) Max
signature.asc
Description: OpenPGP digital signature
