Re: volfile init/reconfigure have been working by accident?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

On Thu, Jul 14, 2016 at 7:25 PM, Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> wrote:
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@xxxxxxxxxx> 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 list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel




--
Pranith



--
Pranith
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux