On Thu, Jul 28, 2016 at 4:13 PM, Niels de Vos <ndevos@xxxxxxxxxx> wrote: > On Thu, Jul 28, 2016 at 03:51:11PM +0530, Prasanna Kalever wrote: >> On Thu, Jul 28, 2016 at 3:32 PM, Niels de Vos <ndevos@xxxxxxxxxx> 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! There are no strict timelines for any of the community work. It > all depends on what your manager(s) want to see in future productized > versions. At the moment, and for all I know, this is just an improvement > that we should do at one point. Yeah, right! Since we are okay with the timelines, I shall get this done to fall with qemu-2.8 Thanks for bringing this into notice :) -- Prasanna > > Niels _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
