On 2018-01-31 19:32, Eric Blake wrote: > 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.
But you were convinced that creating an overlay would play nicely with the internal snapshots? ;-) I'm not sure whether that sounds like a use case I'd want to optimize for, but, well. >>> 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 ;) It could be done as an optimization in a follow-up to this series anyway, yes. Max
signature.asc
Description: OpenPGP digital signature
