[Gluster-devel] Behaviour of glfs_fini() affecting QEMU
Justin Clift
justin at gluster.org
Fri Apr 25 10:06:07 UTC 2014
On 25/04/2014, at 10:40 AM, Deepak Shetty wrote:
> Since nongnu.org was down, I don't see the below mail (avati's and soumya's response) for this mail thread.
> Surpsingly these are not seen in either the nongnu.org or gluster.org archives!
>
> Hence fwding it here in the hope that others can see it.
Thanks for this. :)
And yeah, the outage + migration could produce some weirdness over the next day
or two. Hopefully nothing too serious though.
+ Justin
> ---------- Forwarded message ----------
> From: Bharata B Rao <bharata.rao at gmail.com>
> Date: Fri, Apr 25, 2014 at 3:03 PM
> Subject: Fwd: [Gluster-devel] Behaviour of glfs_fini() affecting QEMU
> To: Deepak Shetty <dpkshetty at gmail.com>
>
>
>
>
> ---------- Forwarded message ----------
> From: Soumya Koduri <skoduri at redhat.com>
> Date: Fri, Apr 25, 2014 at 12:44 PM
> Subject: Re: [Gluster-devel] Behaviour of glfs_fini() affecting QEMU
> To: Anand Avati <avati at gluster.org>
> Cc: Bharata B Rao <bharata.rao at gmail.com>, "Gluster Devel pgurusid at redhat.com" <gluster-devel at nongnu.org>
>
>
> Hi Anand,
>
> Sure. We will then take care of entire cleanup in "glfs_fini()" itself.
>
> Thanks,
> Soumya
>
>
> On 04/25/2014 11:57 AM, Anand Avati wrote:
> Hi Soumya,
>
> Let's have just one cleanup API (which is already called glfs_fini)
> which handles all cases (whether or not glfs_init() was called, whether
> or not it was successful) and frees up all resources. Not only is it a
> bad idea to ask existing applications to make changes to their programs
> to accommodate a new API, it is just too much hassle to make cleanup
> anything more than a single API call.
>
>
>
> On Wed, Apr 23, 2014 at 10:00 AM, Soumya Koduri <skoduri at redhat.com
> <mailto:skoduri at redhat.com>> wrote:
>
> Hi Bharata,
>
> A quick update on this . In the current implementation, we are not
> cleaning up all the memory allocated via "glfs_new" routine (in
> "glfs_fini" i.e, even when glfs_init was done). So after a couple of
> discussions, we have decided to first define a counter cleanup
> routine for glfs_new (may be glfs_destroy as Deepak had suggested)
> to cleanup that memory - Poornima has started working on this and
> then take a call on to whether
>
> * modify glfs_fini itself to detect the init_not_done cases ( Note -
> looks like this check is not so straightforward. We need to come up
> with some method to detect such scenarios) and do the necessary
> cleanup which would mean no changes on the gfapi clients side.
> or
> * document and ask the gfapi clients to update their code and call
> glfs_destroy incase of such failures as suggested by Deepak. This
> seems much cleaner way to address the problem now.
>
> Meanwhile can you please comment on how would it impact Qemu if it
> needs to make an additional call to the libgfapi for the cleanup.
>
> Thanks,
> Soumya
>
>
> ----- Original Message -----
> From: "Deepak Shetty" <dpkshetty at gmail.com <mailto:dpkshetty at gmail.com>>
> To: "Soumya Koduri" <skoduri at redhat.com <mailto:skoduri at redhat.com>>
> Cc: "Bharata B Rao" <bharata.rao at gmail.com
> <mailto:bharata.rao at gmail.com>>, "Gluster Devel"
> <gluster-devel at nongnu.org <mailto:gluster-devel at nongnu.org>>
> Sent: Sunday, April 20, 2014 11:59:40 PM
> Subject: Re: [Gluster-devel] Behaviour of glfs_fini() affecting QEMU
>
> One more late thought...
> Maybe this should show up as "known issues" in the recently released
> gluster 3.5 beta and 3.5 GA release notes (unless fixed, then it
> shud show
> up in FAQs on gluster.org <http://gluster.org>)
>
>
> Can someone from gluster release mgmt take note of this pls ?
>
> thanx,
> deepak
>
>
> On Sun, Apr 20, 2014 at 11:57 PM, Deepak Shetty <dpkshetty at gmail.com
> <mailto:dpkshetty at gmail.com>> wrote:
>
> > This also tells us that the gfapi based validation/QE testcases
> needs to
> > take this scenario in to account
> > so that in future this can be caught sooner :)
> >
> > Bharata,
> > Does the existing QEMU testcase for gfapi cover this ?
> >
> > thanx,
> > deepak
> >
> >
> > On Fri, Apr 18, 2014 at 8:23 PM, Soumya Koduri
> <skoduri at redhat.com <mailto:skoduri at redhat.com>> wrote:
> >
> >> Posted my comments in the bug link.
> >>
> >> " glfs_init" cannot be called before as it checks for
> >> cmds_args->volfile_server which is initialized only in
> >> "glfs_set_volfile_server".
> >> As Deepak had mentioned, we should either define a new routine
> to do the
> >> cleanup incase of init not done or rather modify "glfs_fini" to
> handle this
> >> special case as well which is better approach IMO as it wouldn't
> involve
> >> any changes in the applications using libgfapi.
> >>
> >> Thanks,
> >> Soumya
> >>
> >>
> >> ----- Original Message -----
> >> From: "Bharata B Rao" <bharata.rao at gmail.com
> <mailto:bharata.rao at gmail.com>>
> >> To: "Deepak Shetty" <dpkshetty at gmail.com
> <mailto:dpkshetty at gmail.com>>
> >> Cc: "Gluster Devel" <gluster-devel at nongnu.org
> <mailto:gluster-devel at nongnu.org>>
> >> Sent: Friday, April 18, 2014 8:31:28 AM
> >> Subject: Re: [Gluster-devel] Behaviour of glfs_fini() affecting QEMU
> >>
> >> On Thu, Apr 17, 2014 at 7:56 PM, Deepak Shetty <
> dpkshetty at gmail.com <mailto:dpkshetty at gmail.com> >
>
> >> wrote:
> >>
> >>
> >>
> >>
> >> The glfs_lock indeed seems to work only when glfs_init is
> succesfull!
> >> We can call glfs_unset_volfile_server for the error case of
> >> glfs_set_volfile_server as a good practice.
> >> But it does look like we need a opposite of glfs_new (maybe
> glfs_destroy)
> >> for cases like these to clenaup stuff that glfs_new() allocated
> >>
> >> thats my 2 cents... hope to hear from other gluster core folks
> on this
> >>
> >> There is a launchpad bug tracking this at
> >> https://bugs.launchpad.net/qemu/+bug/1308542
> >>
> >> Regards,
> >> Bharata.
> >>
> >> _______________________________________________
> >> Gluster-devel mailing list
> >> Gluster-devel at nongnu.org <mailto:Gluster-devel at nongnu.org>
>
> >> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> >>
> >
> >
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org <mailto:Gluster-devel at nongnu.org>
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
>
>
>
> --
> http://raobharata.wordpress.com/
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
--
Open Source and Standards @ Red Hat
twitter.com/realjustinclift
More information about the Gluster-devel
mailing list