On Mon, Mar 25, 2019 at 05:01:39PM +0000, Richard W.M. Jones wrote: > > > +=head2 C<.can_extents> [...] > There is definitely a case for removing can_extents completely, and > relying on the fallback. Would this affect language bindings? I > think no because in the language bindings we can also emulate the > .extents callback. > > Associated with this change would be to change the server so it always > advertises and enables base:allocation (if the client requests it). > > I'm trying to think if there's any reason not to make both of those > changes, and failing to think of a reason at the moment ...
Actually I can think of one reason we might want to keep can_extents, and that's the case where a plugin may be able to implement extents in some cases but not others (the file plugin in the current series is an example). However there is still the question of if we should always advertise base:allocation, and I think the answer there is yes we should always advertise that (to clients that ask for it). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
