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: 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: 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: 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: 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
