On 01/31/2018 11:40 AM, Max Reitz wrote: >> Maybe it's good enough to cover these cases: >> 1. no backing >> 2. beyond bdrv_getlength() in backing >> 3. unallocated in backing qcow2 (covers 'beyond bdrv_getlength() >> in backing->file') >> >> 1 & 2 are easy to check; > > Not sure how useful 2 is, though. (I don't know. I always hear about > people wanting to optimize for such a case where a backing file is > shorter than the overlay, but I can't imagine a real use case for that.)
I can; here's what's happened to me personally. I created an image, and took internal snapshots (yeah, I know those aren't in fashion these days, but this was long ago). Later, I ran out of space. I wanted to resize the image, but am not convinced whether resizing the image will play nicely with the internal snapshots (in fact, I don't recall off-hand whether this was something we prevented in the past and now support, or if it is still unsupported now...) - so the easiest way is to create a larger overlay image. > >> 3: if that's not too hacky maybe we can do the bdrv_is_allocated() check >> for qcow2 exclusively and if there is raw (or any other format) backing >> image - do the COW > > Yes, well, it seems useful in principle... But it would require general > block layer work indeed. Maybe a new flag for bdrv_block_status*() that > says only to look into the format layer? Maybe indeed - but first I want my byte-based block_status stuff to land ;) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
