<div dir="ltr">Hmmm... if we modify GF_OPTION_RECONF in such a way that as soon as something succeeds we update the dictionary, then that may work. Not sure if it is clean though. But it is not as bad as allocation/free in all xlators.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 14, 2016 at 7:25 PM, Pranith Kumar Karampuri <span dir="ltr">&lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The problem with approach is if partial reconfigure succeeds/fails we don&#39;t know which keys to update and which ones to not update.<br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Jul 14, 2016 at 5:42 PM, Mohammed Rafi K C <span dir="ltr">&lt;<a href="mailto:rkavunga@redhat.com" target="_blank">rkavunga@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    How about storing the same data variable(from new_xl options dict)
    with a ref in the  options dictionary of old xlator.<br>
    <br>
    Regards<br>
    Rafi KC<div><div><br>
    <br>
    <div>On 07/14/2016 08:28 AM, Pranith Kumar
      Karampuri wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div>
      <div dir="ltr">
        <div>hi,<br>
        </div>
                I wanted to remove &#39;get_new_dict()&#39;, &#39;dict_destroy()&#39;
        usage through out the code base to prevent people from using it
        wrong. Regression for that patch <a href="http://review.gluster.org/13183" target="_blank">http://review.gluster.org/13183</a>
        kept failing and I found that the &#39;xl-&gt;options&#39; dictionary is
        created using get_new_dict() i.e. it doesn&#39;t have any refs. And
        in xlator_members_free() we try to destroy it using dict_unref()
        i.e. ref count becomes &#39;-1&#39; and the dictionary doesn&#39;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
        &#39;xl-&gt;reconfigured_options&#39; 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&#39;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(&#39;fini&#39; should GF_FREE
        all these options), so wondering if anyone has any other
        thoughts on fixing this properly without a lot of code changes.<br clear="all">
        <div>
          <div><br>
            -- <br>
            <div data-smartmail="gmail_signature">
              <div dir="ltr">Pranith<br>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
Gluster-devel mailing list
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a></pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div>