[Gluster-devel] volfile init/reconfigure have been working by accident?

[Pranith Kumar Karampuri]

The problem with approach is if partial reconfigure succeeds/fails we don't
know which keys to update and which ones to not update.

On Thu, Jul 14, 2016 at 5:42 PM, Mohammed Rafi K C <rkavunga at redhat.com>
wrote:

> How about storing the same data variable(from new_xl options dict) with a
> ref in the  options dictionary of old xlator.
>
> Regards
> Rafi KC
>
>
> On 07/14/2016 08:28 AM, Pranith Kumar Karampuri wrote:
>
> hi,
>         I wanted to remove 'get_new_dict()', 'dict_destroy()' usage
> through out the code base to prevent people from using it wrong. Regression
> for that patch http://review.gluster.org/13183 kept failing and I found
> that the 'xl->options' dictionary is created using get_new_dict() i.e. it
> doesn't have any refs. And in xlator_members_free() we try to destroy it
> using dict_unref() i.e. ref count becomes '-1' and the dictionary doesn't
> get destroyed. so every reconfigure is leaking dictionaries. So all the
> options which use string options actually point to the values in these
> dictionaries. Initially I thought we can have latest reconfigured options
> dictionary also stored in new member 'xl->reconfigured_options' but the
> problem is reconfigure can partially succeed leading to dilemma about which
> options succeeded/failed and which dictionary to keep around. Failing in
> reconfigure doesn't stop the brick. At the moment the only way out I see is
> to perform [de]allocation of the string, bool(we can prevent for bool)
> options, may be there are more, I need to check. But this becomes one more
> big patch('fini' should GF_FREE all these options), so wondering if anyone
> has any other thoughts on fixing this properly without a lot of code
> changes.
>
> --
> Pranith
>
>
> _______________________________________________
> Gluster-devel mailing listGluster-devel at gluster.orghttp://www.gluster.org/mailman/listinfo/gluster-devel
>
>
>


-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160714/31845590/attachment.html>