Re: [Gluster-devel] Behaviour of glfs_fini() affecting QEMU

[Soumya Koduri]

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" <address@hidden>
To: "Soumya Koduri" <address@hidden>
Cc: "Bharata B Rao" <address@hidden>, "Gluster Devel" <address@hidden>
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)

Can someone from gluster release mgmt take note of this pls ?

thanx,
deepak


On Sun, Apr 20, 2014 at 11:57 PM, Deepak Shetty <address@hidden> 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 <address@hidden> 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" <address@hidden>
>> To: "Deepak Shetty" <address@hidden>
>> Cc: "Gluster Devel" <address@hidden>
>> 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 < address@hidden >
>> 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
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>
>