On 11/25/2014 03:19 AM, Chen, Hanxiao wrote: >> I think it makes sense to expose this functionality; although I suspect >> it is better if we do so by having the user pass an explicit new flag >> value to existing API instead of doing it automatically. >> > Thanks for your clarification. > > But we've already had nocow in virStorageSource and <nocow> tags. > So I think if we do not specify <nocow> tags in XML, > we should try it according to 'nocow' in codes. > > Or do we need a new flags such as --reflink > for tools like virt-clone?
It's a design trade-off - do we make the default operation efficient when possible (but with possible surprises due to overcommit of storage), or safe (but slow)? Regardless of the default, is it possible to explicitly request the opposite action? To me, it seems backwards compatible to make an operation faster by using underlying clone hooks as long as the end result is the same, and as long as a user NOT specifying a specific use of clone or avoidance of clone does not get an error message when clone is attempted but not supported. So at this point, I could go either way for the default as long as I can still have full control over the behavior, and we don't break existing users. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
