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

2014-04-23 Thread 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 dpkshe...@gmail.com
To: Soumya Koduri skod...@redhat.com
Cc: Bharata B Rao bharata@gmail.com, Gluster Devel 
gluster-devel@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)

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

thanx,
deepak


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




___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel


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

2014-04-20 Thread Deepak Shetty
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 skod...@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@gmail.com
 To: Deepak Shetty dpkshe...@gmail.com
 Cc: Gluster Devel gluster-devel@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  dpkshe...@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@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/gluster-devel

___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel


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

2014-04-20 Thread Deepak Shetty
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 dpkshe...@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 skod...@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@gmail.com
 To: Deepak Shetty dpkshe...@gmail.com
 Cc: Gluster Devel gluster-devel@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  dpkshe...@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@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/gluster-devel



___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel


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

2014-04-20 Thread Vijay Bellur

On Apr 20, 2014 11:59 PM, Deepak Shetty dpkshe...@gmail.com wrote:

 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 ?
Updating known issues in release notes is just one patch away. Please feel free to update release notes by sending a patch.
Thanks,
Vijay 
 thanx,
 deepak


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




___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel


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

2014-04-20 Thread Bharata B Rao
On Sun, Apr 20, 2014 at 11:57 PM, Deepak Shetty dpkshe...@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 ?


If are referring to the test case developed long time back by Poornima,
that just tested if QEMU can boot a VM off GlusterFS backend. We should
first get that test integrated before making further enhancements.

Regards,
Bharata.




___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel


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

2014-04-18 Thread Bharata B Rao
On Fri, Apr 18, 2014 at 8:23 PM, Soumya Koduri skod...@redhat.com wrote:

 Posted my comments in the bug link.


Thanks.



  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.


Anyone from gluster looking into this fix/enhancement ?

Regards,
Bharata.
___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel


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

2014-04-18 Thread Soumya Koduri
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@gmail.com
To: Deepak Shetty dpkshe...@gmail.com
Cc: Gluster Devel gluster-devel@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  dpkshe...@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@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel

___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel


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

2014-04-18 Thread Soumya Koduri
 Anyone from gluster looking into this fix/enhancement ?

I will work on this fix.

Thanks,
Soumya


- Original Message -
From: Bharata B Rao bharata@gmail.com
To: Soumya Koduri skod...@redhat.com
Cc: Deepak Shetty dpkshe...@gmail.com, Gluster Devel 
gluster-devel@nongnu.org
Sent: Friday, April 18, 2014 8:28:21 PM
Subject: Re: [Gluster-devel] Behaviour of glfs_fini() affecting QEMU

On Fri, Apr 18, 2014 at 8:23 PM, Soumya Koduri skod...@redhat.com wrote:

 Posted my comments in the bug link.


Thanks.



  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.


Anyone from gluster looking into this fix/enhancement ?


Regards,
Bharata.

___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel


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

2014-04-17 Thread Deepak Shetty
On Thu, Apr 17, 2014 at 6:58 PM, Bharata B Rao bharata@gmail.comwrote:

 Hi,

 In QEMU, we initialize gfapi in the following manner:

 
 glfs = glfs_new();
 if (!glfs)
goto out;
 if (glfs_set_volfile_server()  0)
goto out;
 if (glfs_set_logging()  0)
goto out;
 if (glfs_init(glfs))
goto out;

 ...

 out:
 if (glfs)
glfs_fini(glfs)
 *

 Now if either glfs_set_volfile_server() or glfs_set_logging() fails, we
 end up doing glfs_fini() which eventually hangs in glfs_lock().

 #0  0x7554a595 in pthread_cond_wait@@GLIBC_2.3.2 () from
 /lib64/libpthread.so.0
 #1  0x779d312e in glfs_lock (fs=0x56331310) at
 glfs-internal.h:176
 #2  0x779d5291 in glfs_active_subvol (fs=0x56331310) at
 glfs-resolve.c:811
 #3  0x779c9f23 in glfs_fini (fs=0x56331310) at glfs.c:753

 Note that we haven't done glfs_init() in this failure case.

 - Is this failure expected ? If so, what is the recommended way of
 releasing the glfs object ?
 - Does glfs_fini() depend on glfs_init() to have worked successfully ?


170 static inline int
171 glfs_lock (struct glfs *fs)
172 {
173 pthread_mutex_lock (fs-mutex);
174
175 while (!fs-init)
176 pthread_cond_wait (fs-cond, fs-mutex);

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

thanx,
deepak


 - Since QEMU-GlusterFS driver was developed when libgfapi was very new,
 can gluster developers take a look at the order of the glfs_* calls we are
 making in QEMU and suggest any changes, improvements or additions now given
 that libgfapi has seen a lot of development ?

 Regards,
 Bharata.
 --
 http://raobharata.wordpress.com/

 ___
 Gluster-devel mailing list
 Gluster-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel


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

2014-04-17 Thread Bharata B Rao
On Thu, Apr 17, 2014 at 7:56 PM, Deepak Shetty dpkshe...@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@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel