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

Deepak Shetty dpkshetty at gmail.com
Sun Apr 20 18:27:25 UTC 2014


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> 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>
> To: "Deepak Shetty" <dpkshetty at gmail.com>
> Cc: "Gluster Devel" <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 >
> 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
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140420/51bfbe0f/attachment-0001.html>


More information about the Gluster-devel mailing list