On 01/31/2018 12:35 PM, Max Reitz wrote: >>> 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? ;-)
Yes. As long as I don't mind pointing back to the original file (rather than the overlay) at the point I attempt to revert to the internal snapshot, then loading the snapshot doesn't have to worry about a size change. > > I'm not sure whether that sounds like a use case I'd want to optimize > for, but, well. I guess it boils down to whether the optimization is a low-maintenance freebie. There's no reason to reject the optimization if a patch demonstrates it is easy to support and it has iotests coverage. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature