[Gluster-devel] Suggestions for improving the block/gluster driver in QEMU

[Prasanna Kalever]

On Thu, Jul 28, 2016 at 3:32 PM, Niels de Vos <ndevos at redhat.com> wrote:
> There are some features in QEMU that we could implement with the
> existing libgfapi functions. Kevin asked me about this a while back, and
> I have finally (sorry for the delay Kevin!) taken the time to look into
> it.
>
> There are some optional operations that can be set in the BlockDriver
> structure. The ones missing that we could have, or have useless
> implementations are these:
>
>   .bdrv_get_info/.bdrv_refresh_limits:
>     This seems to set values in a BlockDriverInfo and BlockLimits
>     structure that is used by QEMUs block layer. By setting the right
>     values, we can use glfs_discard() and glfs_zerofill() to reduce the
>     writing of 0-bytes that QEMU falls back on at the moment.

Hey Niels and Kevin,

In one of our discussions Jeff shown his interest in knowing about
discard support in gluster upstream.
I thinks his intention was same here.

>
>   .bdrv_has_zero_init / qemu_gluster_has_zero_init:
>     Currently always returns 0. But if a file gets created on a Gluster
>     volume, it should never have old contents in it. Rewriting it with
>     0-bytes looks unneeded to me.

I agree

>
> With these improvements the gluster:// URL usage with QEMU (and now also
> the new JSON QAPI), certain operations are expected to be a little
> faster. Anyone starting to work on this would want to trace the actual
> operations (on a single-brick volume) with ltrace/wireshark on the
> system where QEMU runs.
>
> Who is interested to take this on?

Of course I am very much interested to do this work :)

But please expect at least a week or two at initializing this from my side,
as currently my plate is filled with block store tasks.

Hopefully this is meant for 2.8 (as 2.7 is in hard-freeze) I think
delay should be acceptable.

Thanks,
--
Prasanna


> Niels
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel