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/